가상화란?

• 물리적인 컴퓨터 하드웨어를 효율적으로 활용할 수 있도록 해주는 과정.
• 가상화는 소프트웨어를 사용하여 단일 컴퓨터의 하드웨어 요소(프로세서, 메모리, 스토리지)를 다수의 가상 컴퓨터(VM)로 분할해서 사용할 수 있도록 해줌
• 각각의 VM은 자체의 OS를 실행해서 마치 독립적인 컴퓨터처럼 동작함.

가상화의 장점

1. 리소스 효율성 향상

• 가상화 전에는 각 app서버에 물리적인 cpu 가 필요했음 (신뢰성 측면에서 App과 OS/CPU가 1:1 구성)
• 물리 서버는 항상 Full로 사용되지 않기 때문에 효율적으로 Capa를 사용하지 못했음
• 가상화 이후에는 각 VM에서 각자의 OS를 가지고 App을 실행할 수 있어 효율성 및 신뢰성 모두 만족할 수 잇음
• 물리적 하드웨어에 각 VM이 여러개 떠 있는 구조로 유동적으로 자원을 나눠 사용 가능하므로 리소스 효율성도 만족함

2. 가동 중단 시간 최소화

• 여러개의 가상 머신을 띄워서 관리함
• 그 중 하나의 가상 머신 내에서 문제가 발생할 경우 다른 가상 머신을 활용해서 서비스 무중단을 제공함

3.  빠른 자원 제공 

• 물리 서버인 경우 구매, 설치, 구성에는 많은 시간 소요됨
• 가상 머신 활용 시 (하드웨어가 이미 구성되어 있다는 전제 하에) App 실행을 위한 자원을 빠르게 제공 가능
• 전용 SW 사용하여 자원 제공을 자동화하고, 기존 워크플로우에 빌드함으로써 관리의 용이성 제공

가상화의 종류

• 데스크탑 가상화
• 네트워크 가상화
• 스토리지 가상화
• 데이터 가상화
• 애플리케이션 가상화
• 데이터 센터 가상화
• CPU 가상화
• GPU 가상화
• Linux 가상화
• 클라우드 가상화

서버 가상화

• 서버 가상화는 SW를 통해 하나의 물리적인 서버를 여러개의 분리된 가상 서버로 나누는 과정
• 각 가상 서버는 자체 OS를 독립적으로 실행 가능

서버 가상화의 장점

• 서버 가용성 증가
• 운영 비용 절감
• 서버 복잡성 제거
• 애플리케이션 성능 향상
• 더욱 빠른 워크로드 배포

하이퍼바이저란

• 하이퍼바이저는 가상머신을 생성하고 구동하는 SW
• 물리적 리소스를 분리해서 각각의 가상 환경을 만들어주는 역할을 함
• 사용자 또는 프로그램이 물리적 환경의 추가 리소스 요구 시 -> 하이퍼바이저는 그 요청을 물리적 시스템에 전달하고 변경사항을 저장함

하이퍼바이저의 종류

Type 1. Bare-Metal / Native

• 호스트 하드웨어에 직접 설치하여 구동함
• 즉 하드웨어 바로 위에 위치해서 OS역할(하드웨어 제어)을 하고 VM을 관리하는 역할을 함
• 호스트 OS 없어서 OverHead 적음
• 콘솔로 관리해야하므로 사용성 낮음(처음 셋업 시 윈도우 설치처럼 진행해야함)
• 예) Xen, x86용 오라클 VM서버, 마이크로소프트 Hyper-V, VMWare의 ESX 서버

Type 2. Hosted

• 호스트 OS 위에 설치되어 호스트 OS-하이퍼바이저-가상머신 HW간 Overhead 발생함
• APP 설치하는 것처럼 VirtualBox 설치 후 가상머신 이미지 생성하는 방식
• 예) VMWare Workstation, VirtualBox, Mac Paralles 

참고

https://www.ibm.com/kr-ko/topics/virtualization

https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor

MacOS에서 Wireshark로 패킷 분석 실습을 해보자.

먼저 아래 링크에서 WireShark를 다운받는다. 

https://www.wireshark.org/download.html

본인은 Intel CPU라서 그에 맞게 다운했다. 

Wireshark를 Applications로 드래그 앤 드롭해서 설치해준다. 

설치가 완료되었으면 아래 화면을 볼 수 있다. 

Wi-Fi:en1을 클릭하니 아래와 같은 에러가 떴다. 

You do not have permission to capture on device "en1".
((cannot open BPF device) /dev/bpf0: Permission denied)

Please check to make sure you have sufficient permissions.

If you installed Wireshark using the package from wireshark.org, close this dialog and click on the "installing ChmodBPF" link in "You can fix this by installing ChmodBPF." on the main screen, and then complete the installation procedure.

터미널에 아래 명령어를 입력해보자. 

sudo chown gildong /dev/bpf*

정상적으로 실시간 패킷이 잘 확인된다. 

아무튼 이제 다시 돌아오자.

각 패킷이 어디서부터(Source) -> 어디로(Destination) / 어떤 포트를 사용해서 / 패킷을 어느 정도의 길이만큼 주고 받았는지를 확인할 수 있다. 

왼쪽 하단에는 각 패킷의 세부 정보가 나와 있는데 세부 정보에 우클릭을 해서 Apply as Column을 클릭하면

해당 세부 정보를 컬럼으로 추가할 수 있다. 

패킷 필터링

이 많은 패킷들 중 네트워크 지연 분석을 하려면 어떻게 해야할까?

우선 이 많은 패킷들에 필터를 걸어서 원하는 패킷들만 추출해서 볼 수 있어야 한다. 

패킷 필터 방법

패킷 필터 방법은 아래 두 가지가 있다.

1. Capture Filter

• 패킷 수집할 때 부터 필터를 걸어서, 원하는 패킷만 Capture(수집)하는 방법
• 이 방법은 처음 수집할 때부터 조건이 적용되기 때문에 성능에 영향을 줄 수 있다.
• ex. tcp port 443

2. Display Filter

• 먼저 전체 패킷을 수집하고 그 이후에 Display 되는 화면에서 필터를 걸어서 보는 방법
• 다양한 필터 조건을 걸 수 있고, 대게 권장되는 방법이다. 
• ex. tcp.port = 443

패킷 필터 종류

이제 필터의 종류에 대해 알아보자.

우선 필터 예시를 확인해보자.

Analyze > Display Filters 를 클릭하면 

아래와 같이 필터 예시가 나온다. +를 눌러서 자주 쓰는 필터를 추가할 수도 있다. 

유용한 필터들을 자세히 좀 정리해보자.

• 프로토콜 필터 : tcp || udp

패킷 세부 정보를 볼 때 해당 패킷 기준으로 필터를 걸고 싶을 때는 해당 정보에 우클릭 후 Apply as Filter 를 사용하면 된다. 

그럼 위쪽의 필터에 자동으로 ip.src==142.250.256.238 조건이 지정되었고

Source Address가 142.250.256.238 인 패킷들만 display 된 것을 확인할 수 있다. 

Packet Delay 여부를 분석하기 위해서는 어떻게 해야 할까?

우선 가장 기본이 되는 시간 컬럼을 잘 분석해야 한다. 

Req ~ Rep 간에 소요되는 시간이 패킷별로 일정한지, 일정하지 않다면 변화가 생기는 지점을 분석해봐야 한다. 

참고로 시간 포맷은 View > Time Display Format 으로 들어가서 선택할 수 있다. 

Time Column 종류

• Seconds Since First Captured Packet
  • 첫번째 패킷이 캡쳐된 시간을 0으로 지정하고 그 이후의 패킷들은 첫번째 패킷의 시간을 기준으로 비교해서 측정된다. 

• Seconds Since Previous Captured Packet
  • 이전 패킷을 기준으로 다음 패킷이 수집되기까지 (받거나 보내거나) 걸리는 시간을 보여준다. 
  • 아래 예시를 보면 2번 패킷은 1번 패킷이 수집되고 0.003859초만에 왔다.
  • 3번 패킷은 2번 패킷이 수집되고 0.000018초만에 왔다. 
  • 4번 패킷은 3번 패킷이 수집되고 0.000001초만에 왔다. 

• Seconds Since Previous Displayed Packet
  • 화면에 디스플레이 된 패킷들만 대상으로 두고, 이전 패킷을 기준으로 다음 패킷이 수집되기까지(받거나 보내거나) 걸리는 시간을 보여준다.
  • 이 옵션은 필터가 지정되어 있지 않을 때는 위의 Captured Packet 옵션이랑 동일하다.
  • 그러나 필터가 적용되면 아래와 같이 화면에 보여지는 패킷들(조건 지정된 패킷들) 만 대상으로 패킷간에 전달된 시간을 보여준다. 
  • 7번과 9번 패킷을 보면 7번 패킷 이후에 9번 패킷이 오기까지 0.048793초가 걸렸다. 이는 위 사진을 보면 7번~8번 패킷 간 걸린 시간인 0.001079초와 8번~9번 패킷 간 걸린 시간인 0.047714초를 더한 시간임을 알 수 있다. 

네트워크 지연의 원인

1. 흐름 제어 (Flow Control)

수신 측 처리 속도보다 송신 측 전송 속도가 빠를 때 발생한다. 

수신 측의 용량보다 더 빠르게 보내서 패킷이 손실되면(OverFlow), 다시 불필요한 전송과 Ack/Nack 응답을 주고 받아 확인해야하므로 이로 인한 딜레이가 발생할 수 있다. 

해결 방법으로는 Stop and Wait와  Sliding Window 가 있다.

1) Stop and Wait

첫번째 Stop and Wait 방식은 매번 잘 받았다고 응답을 보내야 다음 패킷을 보내는 방식이기 때문에 데이터 유실 없이 안정적인 전송이 가능하겠지만 데이터 전송에 시간이 오래 걸릴 수 있다.

2) Sliding Window

두번째 Sliding Window 방식은 받는 쪽에서 정한 데이터 크기(Window Size) 에 해당하는 패킷들을 전부 보내서 각 패킷의 응답이 오지 않아도 여러 패킷을 보낼 수 있다. 각 패킷별로 잘 받았다는 응답이 와야 다음 패킷을 보낼 수 있는 Stop and Wait 보다 훨씬 효율적인 방법이다. 통신 과정 중에 네트워크가 혼잡하다면 윈도우 크기는 유동적으로 바뀔 수 있다. 

Sliding Window 방식으로 흐름제어를 하지만 이로 인해 데이터 읽기 속도 저하가 발생할 수 있다. 아래를 보자.

* 흐름제어로 인한 데이터 읽기 속도 저하

TCP header 에는 Window Size가 있다. Window Size값이란 수신자가 받을 수 있는 최대 데이터 크기를 의미한다. 

App(수신자)이 네트워크를 통해 전달된 패킷을 받으면 버퍼가 채워지고, App이 데이터를 처리하면(읽으면) 버퍼가 비워진다. 

만약 App의 처리 속도가 1분에 10개의 패킷을 처리한다고 했을 때, Sender 쪽에서 그 보다 더 빠른 속도로 패킷을 전송하면 App의 Window가 점점 차게 된다. 

그럼 Sender 는 데이터의 일부만 보내거나 아예 보낼 수 없는 상황이 발생하고 서버가 전체적으로 지연되는 것이다. 

이런 상황은 어떻게 알 수 있을까?

네트워크에 쓰기 요청을 했는데 그 결과가 0 byte만큼 썼다고 나오면 -> Window Size로 인해 서버 지연이 발생하고 있는 상황을  의심해 볼 수 있다. 

2. 혼잡 제어(Congestion Control)

혼잡제어도 흐름제어와 동일하게 받는 쪽에서 처리하는 데이터 속도보다 보내는 쪽의 속도가 더 빠를 때의 문제를 해결하기 위한 기법이다. 다른점은 혼잡제어는 흐름제어와 달리 보다 넓게 호스트 및 라우터를 포함한다. 

1) AIMD (Additive Increase Multiplicative Decrease)

정상 시 윈도우 크기를 1씩 증가시키면서 보내다가 패킷 전송 실패 혹은 딜레이 발생 시 패킷 전송 속도를 절반으로 줄이는 방식이다. 

처음에 전송 속도가 느리다는 단점과 문제가 발생하고 나서야 개선을 한다는 단점이 있다.

2) Slow Start

AIMD와 비슷하지만 윈도우 크기를 지수적으로 증가시킨다. 즉, 매 RTT마다 2배를 키우다가 (1,2,4,8,16,,) 문제 발생 시 윈도우 크기를 1로 줄인다. 

참고) 

아래 그림은 하드웨어의 네트워크 지연을 나타낸 그림이다.

1. 전송 지연 : 네트워크 장비 자체의 속도로 인함
2. 전파 지연 : 전송 거리로 인함
3. 처리 지연 : 라우터 자체 작업 처리로 인함 (패킷 헤더 처리, 비트 데이터 오류 등)
4. 큐 지연 : 라우터에서 처리하는 중에 추가로 들어오는 데이터들은 큐에 push 후 전송함 

참고) 정상적인 지연 발생 케이스

[정상적인 지연]

앞서 잠깐 언급한 것처럼, 일정 수준의 지연은 많이 발생하기 때문에 이러한 지연은 정상적인 지연으로 분류하고 따로 분석하지 않는다. 정상적인 지연에 해당하는 경우는 아래와 같다.

▶ .ico 파일 요청

- 브라우저 탭에 있는 아이콘을 눌렀을 때 관련 파일을 받아오기 위해 발생하는 지연이다.

▶ SYN 패킷 지연

- 새로운 연결 설정을 위해 첫 SYN 패킷 앞에서 지연이 발생한다.

▶ FIN/RST 패킷

- 연결을 종료하기 위해 사용되는 패킷이다.

- 새로운 탭에서 작업을 수행하거나, 현재 사이트에서 최근 활동이 없을 때, 브라우징 세션이 페이지가 로드된 뒤에 자동으로 닫히도록 구성됐을 때 등의 경우에 지연이 발생한다.

- 사용자가 알 수 없는 지연이다.

▶ GET 요청

- 사용자가 다음 페이지를 요청하거나 백그라운드 프로세스가 페이지 연결을 시도할 경우, 해당 페이지로 연결할 때 지연이 발생한다.

▶ DNS 쿼리

- 여러 개의 하이퍼링크를 가진 페이지가 클라이언트 컴퓨터 상에서 로드될 때 지연이 발생한다.

- 각각의 페이지를 일일이 로드해야 하기 때문에 발생하는 지연이다.

▶ TLS v1 암호화된 경고

- TCP 리셋 바로 전에 발생하는 지연이다.

- 발생 확률은 낮다.

다음 세미나 주제

실제 현장에서 네트워크 딜레이 발생 시 원인 분석을 단계별로 해 나가는 방법 및 실전에서 사용하는 툴

https://blog.ahnlab.com/1288

참고

https://velog.io/@joosing/Wireshark-%ED%8C%A8%ED%82%B7-%ED%95%84%ED%84%B0-A-to-Z

https://as-backup.tistory.com/31

[윈도우 IP/Port 를 활용한 통신 가능 여부 확인 방법]

1.  특정 IP 간 통신 가능 여부 확인  : ping

• 형식 : ping [IP]
• 예)

$ ping 192.168.0.1

$ ping naver.com

• 특정 IP 와의 통신 가능 여부를 확인할 수 있다. 소요되는 시간도 확인 가능하다. 
• ICMP(Internet Control Message Protocol) 가 차단되어 있다면 응답을 얻지 못한다.
• 네트워크 공격 이슈로 차단해 놓은 경우가 많아 추천하지 않는 방법이다.

- ping 명령어 옵션

2. 특정 IP의 특정 Port 접속 가능 여부 확인 : telnet, tcping

• 형식 : telnet [IP] [Port]
• 예)

$ telnet 192.000.000.000 1234
$ telnet naver.com 80

• telnet이란?
  • 기본 개념은 원격 로그인 서비스이지만 서버와 클리이언트 간 통신 확인 용도로 사용된다. 
  • 데이터를 암호화하지 않고 전송해 보안에 취약하며, 원격 로그인 목적으로 사용 시에는 SSH(Secure Shell)을 대신 사용하는 추세이다.
  • 연결 시 Ctrl+Z 대신 Ctrl+']' 를 통해 텔넷 프롬프트로 접속해서 quit 하도록 한다. 
• telnet이 비활성화 되어 있는 경우
  • 제어판>프로그램 및 기능 > Windows 기능 켜기/끄기 >텔넷 클라이언트에 체크박스 체크

• 형식 : tcping [IP] [Port]
• telnet 이 아닌 tcping 으로도 확인이 가능하다. 

$ tcping 192.168.0.1 3000

3. 네트워크 인터페이스의 통신 상태 : netstat

• 형식 : netstat -an|find "[IP]:[Port]"
• 예)

$ netstat -an|find "192.0.0.0:1234"     //특정 ip, port 오픈 여부 확인 

$ netstat -an 							//오픈된 모든 포트 정보 확인

$ netstat -ano | findstr 80   			//특정 포트 정보 확인

* cmd 2개를 열고 한개의 cmd 에서는 telnet 명령어를, 한개의 cmd 에서는 netstat의 명령어를 실행하여 서버-Client 간에 어디에서 방화벽이 막혀 있는지 확인 가능하다. ( 참조 : https://uutopia.tistory.com/entry/%EC%8B%A4%EB%AC%B4%EC%97%90%EC%84%9C-telnet-%EB%AA%85%EB%A0%B9%EC%96%B4%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-%EB%B0%A9%ED%99%94%EB%B2%BD-%ED%99%95%EC%9D%B8%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95) 

[패킷 경로 추적 tracert]

• 패킷 경로 추적에 사용되는 명령어
• 패킷이 거쳐가는 네트워크 경로 상의 장비(라우터, 스위치) 정보와 각 장비의 IP 주소 및 응답 속도를 확인할 수 있다.
• 이를 활용해 속도 지연이 발생되는 구간을 확인할 수 있다.
• 속도 지연이 발생되는 구간의 라우팅 경로를 변경하면 문제 해결이 될 수도 있다.
• ping 명령어와 같이 icmp로 동작하므로 특정 경로에서 icmp 가 차단되어 있다면 정보를 얻지 못한다. (요청 시간 만료로 표시)
• 예)

$ tracert 192.168.0.0 

$ tracert naver.com

• 옵션

-d                 주소를 호스트 이름으로 확인하지 않습니다.
-h maximum_hops    대상 검색을 위한 최대 홉 수입니다.
-j host-list       host-list에 따라 원본 라우팅을 완화합니다(IPv4에만 해당).
-w timeout         각 응답의 대기 시간 제한(밀리초)입니다.
-R                 왕복 경로를 추적합니다(IPv6에만 해당).
-S srcaddr         사용할 원본 주소입니다(IPv6에만 해당).
-4                 IPv4를 사용합니다.
-6                 IPv6을 사용합니다.

[서버 이중화]

• 안정적으로 무중단 서비스를 제공해야 하는 경우에 서버 두 대를 이용한다. 이를 서버 이중화 구조라고 하는데 크게 Active-Active 구조와 Active-Standby 구조로 나뉜다. 
• Zero Down Time 을 달성하기 위함이다.  

(그림 출처  : https://haeunyah.tistory.com/122)

• Active-Active 구조
  • 서버 두 대를 모두 이용하는 방식. 
  • 로드 밸런싱을 해주는 L4 스위치와 같은 하드웨어 장비가 클라이언트로부터 들어온 요청을 적절히 두 개의 서버에 분배한다. (최근에는 하드웨어 뿐 아니라 소프트웨어가 로드밸런서의 역할을 하기도 하나.)
  • 분배하는 기준은 번갈아가면서 주거나, / 부하가 적은 서버에 주거나, / 두 서버에 동시에 주고 응답이 빠른 서버를 선택하는 등의 여러 기준이 있다. 
    • ex. 라운드 로빈, 리스트 커넥션, 리스트 타임, 해시 등
• Active-Standby 구조
  • 서버 두 대중 한 서버만 활용하고 나머지 한 서버는 백업용으로 장애 발생 시 원래 서버에 문제가 발생해서 down되면 백업 서버가 운영 서버로 전환되는 방식이다. 
  • 전환 시에는 자동 또는 수동으로 전환되며 이는 선택 가능하다. 
  • 평소에 Standby 서버도 Active 서버와 동일한 데이터를 가질 수 있도록 동기화 하는 작업이 필요하다. 

* 윈도우에서 서버 이중화 설정하는 방법 (NIC Teamming)

https://pinetreeday.tistory.com/202

[네트워크 용어]

1. Hang Up

• Service Instance 는 실행되고 있으나 멈추는 현상을 말한다. (멈춤)

2. Slow Down

• Service Instance 는 실행되고 있으나 Response Time이 급격히 떨어지는 상태를 말한다. (느려짐)

3. Freezing

• Hang 과 비슷하나, Hang 과 달리 마우스는 움직일 수 있는 상황이다. 

4. DeadLock

• Hang과 비슷하나 특정 요인에 의해 두 개 이상의 프로세스가 한정된 자원을 동시에 요청해서 모든 프로세스들이 일 처리를 하지 못하고 무한 대기 상태가 되는 것이다. 

[RSS]

• RSS란?
  • RSS(Received Side Scaling)는 다중 프로세서 시스템의 여러 CPU에서 네트워크 수신 처리를 효율적으로 배포할 수 있는 네트워크 드라이버 기술이다.
  • RSS가 비활성 된 경우, 모든 프로세싱은 한개의 프로세서에서만 처리하므로 해당 프로세서의 캐시 이용률이 높아져 부하가 발생할 수 있다. 
• RSS가 제공하는 메커니즘
  • 분산 처리
  • 순차 처리
  • 동적 부하 분산
  • 송신 쪽 크기 조정
  • 보안 해시

다음 세미나 준비 주제

 : 서버 성능 향상 방법

 (ex. spec, cpu, mem, heap,,, etc)

참고 : 

https://uutopia.tistory.com/entry/%EC%8B%A4%EB%AC%B4%EC%97%90%EC%84%9C-telnet-%EB%AA%85%EB%A0%B9%EC%96%B4%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EC%97%AC-%EB%B0%A9%ED%99%94%EB%B2%BD-%ED%99%95%EC%9D%B8%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95

• close() 함수 호출을 통해 일방적으로 connection을 종료하면 host 사이에 데이터가 정상적으로 도달하지 못한채 종료되는 경우가 발생할 수 있다.
• 소켓의 스트림은 한쪽 방향으로만 데이터의 이동이 가능하기 때문에 양방향 통신을 위해서는 두개의 스트림이 필요하다.
• host1의 출력 스트림은 host2의 입력 스트림으로, host 2의 출력 스트림은 host1의 입력 스트림으로 이어진다.

[우아한 종료를 위한 shoutdown 함수]

int shutdown(int sock, int howto);

• sock : 종료할 소켓의 파일 디스크립터 전달
• howto : 종료 방법에 대한 정보 전달

1. SHUT_RD : 입력 스트림 종료

2. SHUT_WR : 출력 스트림 종료

3. SHUT_RDWR : 입출력 스트림 종료

[file_client.c]

[file_client.c]

[터미널 실행 결과]

• “Thank you” : 클라이언트 -> 서버 (shutdown 함수 호출 후에 read 함수를 이용하여 클라이언트가 보낸 메세지를 받아왔다.

[1. TCP : echo_client.c / echo_server.c]

<echo_client.c>

<echo_server.c>

<터미널 실행 결과 화면>

서버

클라이언트

tcp 통신의 한계 : 한개의 server는 multiple client와 동시에 통신할 수 없음.

첫번째 클라이언트와 서버가 통신하고 있고, quit 를 하지 않은 상태에서 두번째 클라이언트가 서버에 메세지를 보내면 다시 send back 되지 않는다. (아직 첫번째 클라이언트와 통신하고 있으므로)

> 첫번째 클라이언트가 q 를 눌러서 통신을 종료하면 즉시 두번째 클라이언트에 아까 보냈던 메세지가 send back 되어서 출력된다.

[2. UDP : uecho_client.c / uecho_server.c]

<uecho_server.c>

<uecho_client.c>

<UDP — multiple host 와 커넥션>

• 클라이언트와 서버 역할이 아니라 서로 Host이고 서로 interaction 한다.
• TCP 에서의 문제가 여기서는 발생하지 않는다. ( connectionless)

[3. TCP : op_server.c / op_client.c]

• Really network based application.
• Remote data processing where a client will be making use of the server

<op_client.c>

<op_server.c>

<터미널 결과>

• 클라이언트 자체 내에서 계산한 것이 아니라 클라이언트가 서버에 opeartion을 보낸 후 계산된 결과를 받는 network based application 이다.

• connect 한 다음에 서버쪽에서 ctrl+c로 종료한 다음, 클라이언트에서 opeartion을 수행하면 result 가 0이 나온다. 서버가 응답하지 않았기 때문이다. (trash value)

[4. UDP : bound_host1.c / bound_host2.c]

• Host2에서 Host1으로 msg1, msg2, msg 3를 보낸다.
• Host1에서는 메세지를 받을때마다 5초를 delay 시킨다.

<bound_host1.c>

<bound_host2.c>

• TCP 방식이었다면 delay 해도 host1에서 msg1,msg2,msg3가 한번에 출력되었을 것이다.(data stream)
• 그러나 UDP 방식은 Datagram 형식으로 메세지를 보내므로 5초마다 msg1, msg2, msg3 가 차례로 출력된다.