<div id="readability-page-1" class="page"><div><h2 id="3-way-4-way-handshaketcp-연결-설정과-해제">3-Way, 4-Way Handshake(TCP 연결 설정과 해제)</h2>
<h2 id="background">Background</h2>
<p>기본적인 TCP의 개념과 정의를 알고 있는 상태라고 가정하고 설명한다.  </p>
<h3 id="tcp-연결-상태connection-status">TCP 연결 상태(connection status)</h3>
<ul>
<li><code>CLOSED</code>: 포트가 닫힌 상태</li>
<li><code>LISTEN</code>: 포트가 열린 상태로 연결 요청 대기 상태</li>
<li><code>SYN_RCV</code>: SYNC 요청을 받고 상대방의 응답 대기 상태</li>
<li><code>ESTABLISHED</code>: 포트 연결 상태</li>
</ul>
<h3 id="tcp-플래그flag">TCP 플래그(Flag)</h3>
<ul>
<li><code>SYN</code>: 연결 설정 (Synchronize Sequence Number)</li>
<li><code>ACK</code>: 응답 확인 (Acknowledgement)</li>
<li><code>FIN</code>: 연결 해제 (Finish)</li>
</ul>
<h3 id="tcp-세그먼트segment">TCP 세그먼트(Segment)</h3>
<p>TCP에서의 패킷으로, 전송할 데이터 바이트와 TCP에 의해 데이터에 추가되는 헤더로 구성된다.</p>
<hr>
<h2 id="3-way-handshake">3-Way Handshake</h2>
<p>네트워크 프로토콜 TCP(Transmission Control Protocol)에서 사용되는 연결 설정 방법</p>
<p>데이터를 주고받을 수 있는 두 호스트 간의 연결을 설정하는 과정</p>
<h3 id="the-three-steps-of-a-3-way-handshake"><strong>The Three Steps of a 3-Way Handshake</strong></h3>
<p><strong>Step 1</strong>: 클라이언트가 서버에 연결 요청 (SYN)</p>
<ul>
<li>클라이언트는 서버에 연결하고자 <code>SYN</code>(Synchronize) 패킷 송신</li>
<li>패킷에 클라이언트의 초기 시퀀스 번호를 포함</li>
</ul>
<p><strong>Step 2</strong>: 서버가 클라이언트 요청에 응답 (SYN-ACK)</p>
<ul>
<li>서버는 클라이언트의 <code>SYN</code> 패킷을 수신</li>
<li>클라이언트에 대한 응답으로 <code>SYN-ACK</code>(Synchronize-Acknowledgment) 패킷 송신</li>
<li>패킷에 서버의 초기 시퀀스 번호와 클라이언트의 시퀀스 번호에 1을 더한 값을 포함</li>
</ul>
<p><strong>Step 3</strong>: 클라이언트가 서버에 응답 (ACK)</p>
<ul>
<li>클라이언트는 서버로부터 받은 <code>SYN-ACK</code> 패킷에 대해 <code>ACK</code>(Acknowledgment) 패킷 송신</li>
<li>패킷에 서버의 시퀀스 번호에 1을 더한 값을 포함  </li>
</ul>
<p><img src="https://velog.velcdn.com/images/yeseolee/post/dc702e51-bcb2-4268-ae17-8880b88b0015/image.png"></p>
<p><a href="http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm">http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm</a></p>
<h3 id="why-does-tcp-use-3-way-handshake">Why does TCP use 3-way handshake?</h3>
<ul>
<li>TCP는 연결 지향적 프로토콜로 안정적인 데이터 전송을 위해 신뢰성을 확보하는데 중점을 둠</li>
<li>TCP는 양방향 통신이기 때문에 양쪽 모두 상대방에게 패킷을 보낼 수 있는지 확인</li>
<li>클라이언트와 서버 모두 한 번씩 <code>SYN</code> 와 <code>ACK</code>를 주고받으며 <strong>데이터 수신 여부를 확인</strong>  논리적으로 총 네 단계가 필요한데, 서버의 <code>SYN + ACK</code>를 한 단계로 축약하여 세 단계를 가짐<br>
</li>
</ul>
<h3 id="why-initial-sequence-number-required-to-be-random">Why initial sequence number required to be random?</h3>
<p>동일한 연결의 두 인스턴스가 동일한 시퀀스 번호를 너무 빨리 재사용하는 것, 즉 이전 연결의 세그먼트가 이후 연결의 인스턴스를 방해할 가능성(이전 연결로부터 오는 패킷으로 인식할 가능성)이 있는 경우를 방지하기 위함이다. </p>
<p>TCP 표준 문서 <a href="https://www.rfc-editor.org/rfc/rfc793#section-3.3">RFC793</a> Page.27에 따르면, “To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation” (혼란을 피하기 위해서는 이전 연결의 동일한 시퀀스 번호들이 아직 네트워크에 남아 있을 수 있는 동안, 한 연결의 인스턴스로부터 온 세그먼트들이 사용되는 것을 막아야 합니다) 라고 한다.</p>
<p>(ps. tcp 요청 자체는 하나에서 계속 나가기 때문에, 하나의 것에서 여러 번 요청을 한다는 것을 의미하려고 ‘instance’나 ‘implementation` 대신 ‘incarnation’로 표현한 듯 하다.)</p>
<hr>
<h2 id="4-way-handshake">4-Way Handshake</h2>
<p>TCP 연결을 단계적으로 해제(Connecntion Termination)하는 절차 </p>
<h3 id="the-four-steps-of-a-4-way-handshake"><strong>The Four Steps of a 4-Way Handshake</strong></h3>
<p><strong>Step 1</strong>: 클라이언트가 서버에 연결 종료 요청 (FIN)</p>
<ul>
<li>클라이언트는 서버에 연결을 종료하고자 <code>FIN</code>(Finishing) 패킷 송신</li>
<li>클라이언트는 더 이상 데이터를 전송하지 않을 것임을 알림</li>
</ul>
<p><strong>Step 2</strong>: 서버가 클라이언트 요청에 응답 (ACK)</p>
<ul>
<li>서버는 클라이언트의 <code>FIN</code> 패킷 수신</li>
<li>수신을 확인하기 위해 <code>ACK</code>(Acknowledgment) 패킷 송신</li>
<li>클라이언트는 아직 서버 쪽에서 데이터를 받을 수 있음</li>
</ul>
<p><strong>Step 3</strong>: 서버가 클라이언트에 연결 종료 요청 (FIN)</p>
<ul>
<li>서버는 자신의 데이터 전송이 끝났음을 알리기 위해 <code>FIN</code>패킷을 송신</li>
</ul>
<p><strong>Step 4</strong>: 클라이언트가 서버 요청에 응답 (ACK)</p>
<ul>
<li>클라이언트는 서버의 <code>FIN</code> 패킷 수신</li>
<li>수신을 확인하기 위해 <code>ACK</code>패킷 송신</li>
<li>클라이언트는 더 이상 서버로 데이터를 받지 않을 것임을 인지</li>
</ul>
<p><img src="https://velog.velcdn.com/images/yeseolee/post/04e96a03-8f12-4cb5-b915-3a653bae76db/image.png"></p>
<p><a href="http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm">http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm</a></p>
<h2 id="time_wait">TIME_WAIT</h2>
<ul>
<li>Connection을 먼저 종료하는&nbsp;<strong>Active Closer</strong>가 Connection 종료 후 도달하는 상태  ※ Close 요청을 먼저한 주체가 누구냐에 따라 <strong>Active Close</strong>, <strong>Passive Close</strong> 대상이 달라진다, 먼저 close 요청한 쪽이 Active Close.<br>
</li>
<li>Network에 남아 있을 수 있는 종료된 Connection의 Packet이 완전히 제거될 때까지 대기</li>
<li>이후에 생성되는 새로운 Connection에 영향을 미치지 않기 위한 용도로 이용되는 상태</li>
</ul>
<h3 id="problems-if-time_wait-is-short">Problems if TIME_WAIT is short</h3>
<ol>
<li>
<p><strong>Packet Delay</strong>에 의해서 새로운 Connection이 이전 Connection의 영향을 받는 상황</p>
<p><img src="https://velog.velcdn.com/images/yeseolee/post/54c984b4-d19c-47e3-9ded-f9673e705945/image.png"></p>
<ul>
<li>붉은 선으로 표시 된 Client가 전송한 SEQ=3 Packet이 지연됨</li>
<li>Client와 Server가 기존의 Connection을 종료하고 새로운 Connection을 맺음</li>
<li>이후에 이전 Connection의 지연된 SEQ=3 Packet이 Server에게 전달</li>
<li>Server가 받아야 하는 SEQ와 지연된 Packet의 SEQ가 다르면 Server에서는 Drop하기 때문에 문제가 발생하지 않음</li>
<li>하지만 <strong>Server가 수신해야 하는 SEQ와 지연된 Packet의 SEQ가 우연히 동일한 경우</strong>에는 Server는 지연된 Packet을 Drop하지 않고 수신하여 Data 무결성이 깨진다.</li>
</ul>
</li>
<li>
<p>원격 종단의 연결이 닫혔는지 확인해야할 경우 (TCP 4-Way Handshake의 마지막 <code>ACK</code> Flag가 Server(<strong>Passive Closer</strong>)에게 전달되지 않아 Server가 <code>LAST_ACK</code> 상태를 유지하는 상황)</p>
<p><img src="https://velog.velcdn.com/images/yeseolee/post/5561fbef-19f5-44ae-9330-a35232d1ce2e/image.png"></p>
<ul>
<li>Server의 <code>LAST_ACK</code> 상태가 <strong>Timeout</strong>에 의해서 <code>CLOSED</code> 상태로 변경 되기전, Client는 새로운 Connection을 위해서 동일한 Local IP/Port를 이용하여 Server에게 <code>SYN</code> Flag를 전송</li>
<li><code>LAST_ACK</code> 상태의 Server는 <code>SYN</code> Flag를 받을 경우 <code>RST</code> FLAG를 전송하여 Connection 생성을 막기 때문에 새로운 Connection 생성 실패</li>
</ul>
</li>
</ol>
<h3 id="avoiding-time_wait">Avoiding TIME_WAIT</h3>
<ul>
<li><code>tcp_timestamps</code></li>
<li><code>tcp_tw_reuse</code></li>
<li><code>tcp_tw_recycle</code></li>
<li><code>Socket Lingering</code></li>
</ul>
<hr>
<h2 id="3-way-handshake-vs-4-way-handshake">3-Way Handshake vs 4-Way Handshake</h2>
<p>연결 설정 시에는 클라이언트의 연결 요청 시점과 서버의 연결 요청 시점이 거의 동시에 진행된다. 따라서 서버는 클라이언트에 대한 응답과 연결 요청을 <code>SYN + ACK</code> 로 압축하여 보낼 수 있다.  </p>
<p>연결 종료 시에는 클라이언트가 데이터 전송을 마쳤다고 하더라도 서버는 아직 보낼 데이터가 남아있을 수 있기 때문에, <code>FIN</code>에 대한 <code>ACK</code>만 우선적으로 보낸다. 데이터를 모두 전송한 이후에 <code>FIN</code> 메시지를 보낸다.</p>
<hr>
<p>참고</p>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc793">https://www.rfc-editor.org/rfc/rfc793</a></li>
<li><a href="https://www.ibm.com/docs/en/zos/2.1.0?topic=SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/constatus.html">https://www.ibm.com/docs/en/zos/2.1.0?topic=SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/constatus.html</a></li>
<li><a href="http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm">http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm</a></li>
<li><a href="http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm">http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm</a></li>
<li><a href="https://velog.io/@averycode/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-TCPUDP%EC%99%80-3-Way-Handshake4-Way-Handshake#3-way-handshake%EC%9D%98-%EA%B8%B0%EB%B3%B8%EB%A7%A4%EC%BB%A4%EB%8B%88%EC%A6%98">https://velog.io/@averycode/네트워크-TCPUDP와-3-Way-Handshake4-Way-Handshake#3-way-handshake의-기본매커니즘</a></li>
<li><a href="https://ssup2.github.io/theory_analysis/TCP_TIME_WAIT_State">https://ssup2.github.io/theory_analysis/TCP_TIME_WAIT_State</a></li>
<li><a href="https://docs.likejazz.com/time-wait">https://docs.likejazz.com/time-wait</a></li>
<li><a href="https://serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html">https://serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html</a></li>
</ul></div></div>

yeseolee.log

3-Way, 4-Way Handshake(TCP 연결 설정과 해제)
Background
기본적인 TCP의 개념과 정의를 알고 있는 상태라고 가정하고 설명한다.  
TCP 연결 상태(connection status)
CLOSED: 포트가 닫힌 상태
LISTEN: 포트가 열린 상태로 연결 요청 대기 상태
SYN_RCV: SYNC 요청을 받고 상대방의 응답 대기 상태
ESTABLISHED: 포트 연결 상태
TCP 플래그(Flag)
SYN: 연결 설정 (Synchronize Sequence Number)
ACK: 응답 확인 (Acknowledgement)
FIN: 연결 해제 (Finish)
TCP 세그먼트(Segment)
TCP에서의 패킷으로, 전송할 데이터 바이트와 TCP에 의해 데이터에 추가되는 헤더로 구성된다.
3-Way Handshake
네트워크 프로토콜 TCP(Transmission Control Protocol)에서 사용되는 연결 설정 방법
데이터를 주고받을 수 있는 두 호스트 간의 연결을 설정하는 과정
The Three Steps of a 3-Way Handshake
Step 1: 클라이언트가 서버에 연결 요청 (SYN)
클라이언트는 서버에 연결하고자 SYN(Synchronize) 패킷 송신
패킷에 클라이언트의 초기 시퀀스 번호를 포함
Step 2: 서버가 클라이언트 요청에 응답 (SYN-ACK)
서버는 클라이언트의 SYN 패킷을 수신
클라이언트에 대한 응답으로 SYN-ACK(Synchronize-Acknowledgment) 패킷 송신
패킷에 서버의 초기 시퀀스 번호와 클라이언트의 시퀀스 번호에 1을 더한 값을 포함
Step 3: 클라이언트가 서버에 응답 (ACK)
클라이언트는 서버로부터 받은 SYN-ACK 패킷에 대해 ACK(Acknowledgment) 패킷 송신
패킷에 서버의 시퀀스 번호에 1을 더한 값을 포함  
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
Why does TCP use 3-way handshake?
TCP는 연결 지향적 프로토콜로 안정적인 데이터 전송을 위해 신뢰성을 확보하는데 중점을 둠
TCP는 양방향 통신이기 때문에 양쪽 모두 상대방에게 패킷을 보낼 수 있는지 확인
클라이언트와 서버 모두 한 번씩 SYN 와 ACK를 주고받으며 데이터 수신 여부를 확인
  논리적으로 총 네 단계가 필요한데, 서버의 SYN + ACK를 한 단계로 축약하여 세 단계를 가짐
Why initial sequence number required to be random?
동일한 연결의 두 인스턴스가 동일한 시퀀스 번호를 너무 빨리 재사용하는 것, 즉 이전 연결의 세그먼트가 이후 연결의 인스턴스를 방해할 가능성(이전 연결로부터 오는 패킷으로 인식할 가능성)이 있는 경우를 방지하기 위함이다. 
TCP 표준 문서 RFC793 Page.27에 따르면, “To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation” (혼란을 피하기 위해서는 이전 연결의 동일한 시퀀스 번호들이 아직 네트워크에 남아 있을 수 있는 동안, 한 연결의 인스턴스로부터 온 세그먼트들이 사용되는 것을 막아야 합니다) 라고 한다.
(ps. tcp 요청 자체는 하나에서 계속 나가기 때문에, 하나의 것에서 여러 번 요청을 한다는 것을 의미하려고 ‘instance’나 ‘implementation` 대신 ‘incarnation’로 표현한 듯 하다.)
4-Way Handshake
TCP 연결을 단계적으로 해제(Connecntion Termination)하는 절차 
The Four Steps of a 4-Way Handshake
Step 1: 클라이언트가 서버에 연결 종료 요청 (FIN)
클라이언트는 서버에 연결을 종료하고자 FIN(Finishing) 패킷 송신
클라이언트는 더 이상 데이터를 전송하지 않을 것임을 알림
Step 2: 서버가 클라이언트 요청에 응답 (ACK)
서버는 클라이언트의 FIN 패킷 수신
수신을 확인하기 위해 ACK(Acknowledgment) 패킷 송신
클라이언트는 아직 서버 쪽에서 데이터를 받을 수 있음
Step 3: 서버가 클라이언트에 연결 종료 요청 (FIN)
서버는 자신의 데이터 전송이 끝났음을 알리기 위해 FIN패킷을 송신
Step 4: 클라이언트가 서버 요청에 응답 (ACK)
클라이언트는 서버의 FIN 패킷 수신
수신을 확인하기 위해 ACK패킷 송신
클라이언트는 더 이상 서버로 데이터를 받지 않을 것임을 인지
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
TIME_WAIT
Connection을 먼저 종료하는 Active Closer가 Connection 종료 후 도달하는 상태
  ※ Close 요청을 먼저한 주체가 누구냐에 따라 Active Close, Passive Close 대상이 달라진다, 먼저 close 요청한 쪽이 Active Close.
Network에 남아 있을 수 있는 종료된 Connection의 Packet이 완전히 제거될 때까지 대기
이후에 생성되는 새로운 Connection에 영향을 미치지 않기 위한 용도로 이용되는 상태
Problems if TIME_WAIT is short
Packet Delay에 의해서 새로운 Connection이 이전 Connection의 영향을 받는 상황
 
붉은 선으로 표시 된 Client가 전송한 SEQ=3 Packet이 지연됨
Client와 Server가 기존의 Connection을 종료하고 새로운 Connection을 맺음
이후에 이전 Connection의 지연된 SEQ=3 Packet이 Server에게 전달
Server가 받아야 하는 SEQ와 지연된 Packet의 SEQ가 다르면 Server에서는 Drop하기 때문에 문제가 발생하지 않음
하지만 Server가 수신해야 하는 SEQ와 지연된 Packet의 SEQ가 우연히 동일한 경우에는 Server는 지연된 Packet을 Drop하지 않고 수신하여 Data 무결성이 깨진다.
원격 종단의 연결이 닫혔는지 확인해야할 경우 (TCP 4-Way Handshake의 마지막 ACK Flag가 Server(Passive Closer)에게 전달되지 않아 Server가 LAST_ACK 상태를 유지하는 상황)
 
Server의 LAST_ACK 상태가 Timeout에 의해서 CLOSED 상태로 변경 되기전, Client는 새로운 Connection을 위해서 동일한 Local IP/Port를 이용하여 Server에게 SYN Flag를 전송
LAST_ACK 상태의 Server는 SYN Flag를 받을 경우 RST FLAG를 전송하여 Connection 생성을 막기 때문에 새로운 Connection 생성 실패
Avoiding TIME_WAIT
tcp_timestamps
tcp_tw_reuse
tcp_tw_recycle
Socket Lingering
3-Way Handshake vs 4-Way Handshake
연결 설정 시에는 클라이언트의 연결 요청 시점과 서버의 연결 요청 시점이 거의 동시에 진행된다. 따라서 서버는 클라이언트에 대한 응답과 연결 요청을 SYN + ACK 로 압축하여 보낼 수 있다.  
연결 종료 시에는 클라이언트가 데이터 전송을 마쳤다고 하더라도 서버는 아직 보낼 데이터가 남아있을 수 있기 때문에, FIN에 대한 ACK만 우선적으로 보낸다. 데이터를 모두 전송한 이후에 FIN 메시지를 보낸다.
참고
https://www.rfc-editor.org/rfc/rfc793
https://www.ibm.com/docs/en/zos/2.1.0?topic=SSLTBW_2.1.0/com.ibm.zos.v2r1.halu101/constatus.html
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
https://velog.io/@averycode/네트워크-TCPUDP와-3-Way-Handshake4-Way-Handshake#3-way-handshake의-기본매커니즘
https://ssup2.github.io/theory_analysis/TCP_TIME_WAIT_State
https://docs.likejazz.com/time-wait
https://serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

3-Way, 4-Way Handshake(TCP 연결 설정과 해제)

댓글