1. 연결 관리
TCP는 연결 지향 프르토콜이므로 데이터 전송 전에 handshake를 한다.
1) 2-way handshake를 하지 않는 이유
client가 서버에게 connection request를 보낸다.
서버는 client에게 connection accept를 보낸다.
데이터 전송이 끝나고 연결을 종료한다. (서버는 클라이언트와의 연결에 대해 저장하지 않는다.)
중간에 connection accept 메세지가 늦게 도착해서 client가 재요청을 보낸게 연결 종료 후 서버에 도착한다면,
서버는 새로운 connection request라고 생각하게된다.
connection 재요청이 연결 종료 후 도착하고, 그 후에 데에터 요청까지 늦게 도착한다면, 서버는 response를하게되고, garbage data가 발생하게되는 것이다.
2) TCP 3-way handshake
(1) TCP 3-way handshake 과정
클라이언트 입장에서는, 서버에게 연결 요청을 보내고, 서버로부터 accept를 받으면 establish된다. (2-way와 동일)
서버 입장에서, 연결 요청이 오고나서는 이게 언제 요청을 보냈는지 알 수 없다.(client가 alive인지)
그러므로, accept 를 client에게 보내고, client로부터 ack를 받으면, 그 때 client가 alive이라고 판단하고 establish 된다.
구체적으로 과정을 다시 살펴보면,
client가 최초 seq num x와 SYN 메세지를 보낸다. (SYNbit = 1, Seq=x)
서버는 최초 seq num y와 SYNACK을 보낸다. (SYN bit = 1, Seq = y, ACKbit = 1, ACKnum = x+1)
클라이언트가 SYNACK(x)를 받았다는 것은 서버가 live 상태라는 것을 의미한다. 그러므로 ESTAB 상태가 되고, SYNACK에 대한 ACK를 보낸다. 이 세그먼트에는 client-to-server 데이터를 포함할 수 있다. (ACKbit=1, ACKnum=y+1)
서버는가 ACK(y)를 받았다는 것은 클라이언트가 live 상태라는 것을 의미하므로 ESTAB 상태가 된다.
(2) TCP 3-way handshake FSM(Finite State Machine)
netstat을 이용해 "상태" 값에 TCP소켓의 FSM을 확인할 수 있다.)
서버 동작 | 동작 후 서버 상태 | 동작 후 클라이언트 상태 | 클라이언트 동작 |
Closed | Closed | ||
welcom socket 생성 | Listen | ||
SYN sent (서버의 SYNACK을 기다리는 상태) |
application에서 client socket 생성하면 TCP에서 서버에게 client 를 위한 SYN 메세지 전송 |
||
클라이언트로부터 SYN 메세지 바으면, 해당 클라이언트에게 SYNACK 전송, 클라이언트와 통신하기위한 소켓 생성 | SYNrcvd (클라이언트에게 ACK를 기다리는 상태) | ||
ESTAB | SYNACK을 받으면 ACK를 보냄 |
||
ACK 수신 | ESTAB |
(3) FSM 상태/메세지와 설명 (표 출처 )
상태 | 상태 설명 | 이벤트 및 전환 |
CLOSED | 이것은 각 연결이 설정 프로세스가 시작되기 전에 시작하는 기본 상태입니다. 이 상태는 표준에서 "가상"이라고 합니다. 그 이유는 이 상태가 장치 간에 연결이 없는 상황을 나타내기 때문입니다. 아직 만들어지지 않았거나 방금 파괴된 것입니다. 이해가 되시나요? J | 수동 오픈: 서버는 TCP 포트에서 수동 오픈을 수행하여 연결 설정 프로세스를 시작합니다. 동시에 연결을 관리하는 데 필요한 데이터 구조( 전송 제어 블록 또는 TCB )를 설정합니다. 그런 다음 LISTEN 상태로 전환합니다. |
Active Open, Send SYN : 클라이언트는 SYN 메시지를 보내 연결 설정을 시작하고 , 이 연결에 대한 TCB도 설정합니다. 그런 다음 SYN-SENT 상태로 전환합니다. | ||
LISTEN | 장치(일반적으로 서버)는 클라이언트로부터 동기화 ( SYN ) 메시지를 수신하기를 기다리고 있습니다. 아직 자체 SYN 메시지를 보내지 않았습니다 . | 클라이언트 SYN 수신 , SYN+ACK 전송 : 서버 장치 가 클라이언트로부터 SYN을 수신합니다. 자체 SYN을 포함 하고 수신한 SYN을 확인하는 메시지를 다시 보냅니다 . 서버는 SYN-RECEIVED 상태로 이동합니다. |
SYN-SENT | 장치(일반적으로 클라이언트)는 동기화 ( SYN ) 메시지를 보냈 으며 다른 장치(일반적으로 서버)에서 일치하는 SYN을 기다리고 있습니다 . | SYN 수신 , ACK 전송 : SYN 메시지 를 보낸 장치가 다른 장치로부터 SYN 을 받았지만 자신의 SYN 에 대한 ACK를 받지 못한 경우 , 수신한 SYN 을 확인한 후 SYN-RECEIVED 로 전환하여 자신의 SYN 에 대한 확인을 기다립니다 . |
SYN+ACK 수신 , ACK 전송 : SYN 을 보낸 장치가 SYN 에 대한 확인 과 다른 장치에서 SYN 을 모두 받으면 수신한 SYN 을 확인 하고 바로 ESTABLISHED 상태로 이동합니다. | ||
SYN-RECEIVED | 이 장치는 파트너로부터 SYN (연결 요청)을 수신 하고 자체 SYN을 보냈습니다. 이제 연결 설정을 완료하기 위해 SYN 에 대한 ACK 를 기다리고 있습니다 . | ACK 수신 : 장치가 보낸 SYN 에 대한 ACK를 받으면 ESTABLISHED 상태로 전환됩니다. |
ESTABLISHED | 열린 TCP 연결의 "안정 상태". 연결에 있는 두 장치가 이 상태에 들어가면 데이터를 자유롭게 교환할 수 있습니다. 이는 어떤 이유로든 연결이 닫힐 때까지 계속됩니다. | 닫기, FIN 전송 : 장치는 FIN ( 종료 ) 비트가 전송되고 FIN-WAIT-1 상태로 전환되는 메시지를 보내어 연결을 닫을 수 있습니다 . |
FIN 수신 : 장치는 연결 파트너로부터 연결을 닫으라는 FIN 메시지를 받을 수 있습니다. 이 메시지를 확인하고 CLOSE-WAIT 상태로 전환합니다. | ||
CLOSE-WAIT | 장치가 다른 장치로부터 닫기 요청( FIN ) 을 받았습니다 . 이제 로컬 장치의 애플리케이션이 이 요청을 확인하고 일치하는 요청을 생성할 때까지 기다려야 합니다. | 닫기, FIN 전송 : TCP를 사용하는 애플리케이션은 다른 프로세스가 종료하려 한다는 알림을 받고 실행 중인 머신의 TCP 계층에 닫기 요청을 보냅니다. 그런 다음 TCP는 이미 연결을 종료하도록 요청한 원격 디바이스에 FIN 을 보냅니다. 이 디바이스는 이제 LAST-ACK 로 전환됩니다 . |
LAST-ACK | 이미 닫기 요청을 받고 이를 확인한 장치는 자체 FIN을 전송했으며 이 요청에 대한 ACK 를 기다리고 있습니다 . | FIN 에 대한 ACK 수신 : 장치는 닫기 요청에 대한 확인을 받습니다. 이제 우리는 FIN을 보냈고 확인을 받았으며 다른 장치의 FIN을 받고 확인을 받았으므로 바로 CLOSED 상태로 이동합니다. |
FIN-WAIT-1 | 이 상태의 장치는 자신이 보낸 FIN 에 대한 ACK를 기다리 거나 다른 장치로부터 연결 종료 요청을 기다리고 있습니다. | FIN 에 대한 ACK 수신 : 장치는 닫기 요청에 대한 확인을 받습니다. FIN-WAIT-2 상태로 전환됩니다. |
FIN 수신 , ACK 전송 : 디바이스는 자신의 FIN 에 대한 ACK를 받지 못하지만 , 다른 디바이스로부터 FIN 을 받습니다 . 이를 확인하고 CLOSING 상태로 이동합니다. | ||
FIN-WAIT-2 | 이 상태의 장치는 연결 종료 요청에 대한 ACK를 받았으며 이제 다른 장치로부터 일치하는 FIN 을 기다리고 있습니다. | FIN 수신 , ACK 전송 : 장치는 다른 장치로부터 FIN 을 수신합니다. 이를 확인하고 TIME-WAIT 상태로 이동합니다. |
CLOSING | 해당 장치는 다른 장치로부터 FIN 을 수신 하고 이에 대한 ACK를 보냈지 만, 아직 자신의 FIN 메시지에 대한 ACK를 받지 못했습니다 . | FIN 에 대한 ACK 수신 : 장치는 닫기 요청에 대한 확인을 받습니다. TIME-WAIT 상태로 전환됩니다. |
TIME-WAIT | 이제 장치는 다른 장치에서 FIN 을 수신 하고 이를 확인하고 자체 FIN을 전송하고 이에 대한 ACK를 수신했습니다 . ACK가 수신되었는지 확인하고 새 연결과의 잠재적 중복을 방지하기 위해 기다리는 것을 제외하고는 완료되었습니다. | 타이머 만료: 지정된 대기 기간 후 장치는 CLOSED 상태로 전환됩니다. |
2) TCP 4-way handshake
(1) TCP 연결 종료
클라이언트, 서버 각각이 연결을 종료한다.(FIN bit = 1인 TCP 세그먼트 전송. 마지막 세그먼트에 사용자 데이터를 포함할 수 도있다.)
서버는 수신된 FIN에 ACK로 응답한다.(FIN을 받으면, ACK를 자체 FIN과 결합할 수 있다)
서버와 클라이언트 동작이 독립적으로 일어날 수 있으므로 동시 FIN 교환 처리 가능하다.
연결 종료는 주로 클라이언트에서 먼저 보낸다.
클라이인트가 FINbit를 보내도 서버는 계속해서 데이터를 보낼 수 있다. 그 이유는 클라이언트가 FINbit를 보냈다는 것은 클라이언트 -> 서버 전송을 종료하겠다는 의미이므로, 수신은 가능하다.
서버가 ACKbit를 받으면, 서버는 CLOSED 상태가 되고, 소켓, tcp 프로세스 등을 회수한다.
그러나 클라이언트는 ACK를 보내고도 세그먼트 최대 수명의 2배 기간동안 대기한다. 그 이유는, 서버로 보낸 ACK가 유실되면, 서버는 ACK를 기다리다가, timeout이 발생하고, 재전송 해야하기 때문이다.)
'CS > 네트워크' 카테고리의 다른 글
[네트워크] 전송 계층 - TCP 혼잡 제어 (0) | 2025.01.12 |
---|---|
[네트워크] 전송 계층 - 혼잡 제어 원리 (0) | 2025.01.12 |
[네트워크] 전송 계층 - TCP : 흐름 제어 (0) | 2025.01.12 |
[네트워크] 전송 계층 - TCP : 신뢰성있는 데이터 전송 (0) | 2025.01.12 |
[네트워크] 전송 계층 - TCP : segment 구조 (0) | 2025.01.12 |