Ch 09. 내용 확인문제

    모든 내용은 [윤성우 저, "열혈강의 TCP/IP 소켓 프로그래밍", 오렌지미디어] 를 기반으로 제 나름대로 이해하여 정리한 것입니다. 다소 부정확한 내용이 있을수도 있으니 이를 유념하고 봐주세요!

---

01. 다음 중 Time-wait 상태에 대해서 맞게 설명한 것을 모두 고르면?

b. 연결종료의 Four-way handshaking 과정에서 먼저 FIN 메세지를 전달한 소켓이 Time-wait 상태가 된다.

# 틀린 설명

a. Time-wait 상태는 서버 프로그램에서 생성한 소켓에서만 발생한다.
=> 소켓의 Time-wait 상태는 클라이언트냐 서버냐와는 상관없이

먼저 연결의 종료를 요청(FIN 메시지 전달)한 소켓은 반드시 Time-wait 상태를 거친다.
그러나 클라이언트 소켓의 PORT번호는 connect 함수호출시 임의로 할당되기 때문에,

클라이언트에서는 Time-wait 상태를 크게 신경쓰지 않아도 된다.

c. 연결요청 과정에서 전송하는 SYN 메세지의 전송순서에 따라서 Time-wait 상태는 연결종료와 상관없이 일어날 수 있다.
=> Time-wait 상태는 "연결종료 과정에서 먼저 FIN 메세지를 전송한 소켓"에게 발생한다.

d. Time-wait 상태는 불필요하게 발생하는 것이 대부분이므로, 가급적이면 발생하지 않도록 소켓의 옵션을 변경해야 한다.
=> 서버를 빨리 재가동시켜서 서비스를 이어나가야 할 경우에는 Time-wait 상태가 불필요할 수 있으나,

Time-wait 상태는 상대 호스트의 정상적 종료를 보장하기에 중요하다.

---

2. 옵션 TCP_NODELAY는 Nagle 알고리즘과 관련이 있다. 이 옵션을 이용해서 Nagle 알고리즘을 해제할 수도 있는데,
그렇다면 어떠한 경우에 한해서 Nagle 알고리즘의 해제를 고민해 볼 수 있겠는가? 이를 송수신하는 데이터의 특성과 관련해서 설명해보자.

 

# 일반적으로 Nagle 알고리즘을 적용하면 속도의 향상을 기대할 수 있으나,
데이터의 특성을 정확히 판단후, 더 좋은 방법이 있다면 중단한다.

# Nagle 알고리즘의 중단
- "Nagle 알고리즘의 적용 여부에 따른 트래픽의 차이가 크지 않으면서도,

Nagle 알고리즘을 적용하는 것보다 데이터 전송이 빠른 경우" 중단

 

e.g. "용량이 큰 파일 데이터의 전송"
파일 데이터를 출력버퍼로 밀어넣는 작업은 시간이 거의 걸리지 않으므로,
Nagle을 적용하지 않아도 출력버퍼를 거의 꽉채운 상태에서 패킷을 전송하게 됨

e.g. 전송해야 할 데이터의 양이 많은 경우
출력버퍼로 전달되는 데이터의 양이 많으면, Nagle 알고리즘의 적용 여부에 상관없이 충분히 버퍼링 되서 데이터가 전달됨

 

=> 패킷 수가 크게 증가하지도 않고, ACK를 기다리지 않고 연속해서 데이터를 전송하여 전송속도도 크게 향상함

---

 

[출처] : 윤성우 저, "열혈강의 TCP/IP 소켓 프로그래밍", 오렌지미디어