[Network] 프로토콜 스택의 데이터 송/수신, 말소 과정 알아보기

저번 포스팅에서는 프로토콜 스택 및, 위에서 소켓 작성에 대한 부분을 알아보았었다.

이번 포스팅에서는 구체적으로 프로토콜 스택의 데이터 송수신 및 말소 과정에 대해서 알아보고자 한다.

 

---

✔️ 소켓에 접속하기

소켓을 만들면 애플리케이션 (브라우저)는 connect()를 호출하고, 프로토콜 스택은 본인 쪽의 소켓을 서버 측에 접속한다.

이더넷이나 통신 회선은 기본적으로 항상 케이블이 연결되어 있기 때문에, 언제든지 신호를 보낼 수 있어서 데이터를 신호로만 변환하면 된다. 하지만 만약 소켓을 만든 다음에 애플리케이션에서 송신 의뢰가 온다면, 프로토콜 스택은 어떻게 될까?

 

우선, 기본적으로 소켓을 생성한 다음에는 아무것도 없기 때문에 통신 상대도 모른다.

그래서 의뢰가 온다면 데이터를 어디로 보내면 좋을지도 알 수 없다.

 

브라우저는 URL을 바탕으로 서버의 IP 주소를 조사하고, 포트는 보통 80번으로 고정되어 있다는 정보는 알고 있지만, 이걸로는 socket() 메서드를 호출하더라도 아무 일도 발생하지 않는다. 그래서 서버의 IP나 포트 번호를 프로토콜 스택에 알리는 동작이 우선으로 필요하다.

마찬가지로 서버 역시 소켓을 생성하는 것만으로는 브라우저에 대해 아무 정보도 알 수 없기 때문에, 클라이언트는 보통 본인의 IP와 포트 번호를 바탕을 알려서 통신하고 싶다는 것을 전달한다.

 

즉, 처음에는  통신 상대와 제어 정보를 주고받아 소켓에 필요한 정보 기록하고 데이터를 송/수신이 가능한 상태로 변경한다.

여기서 클라이언트 측의 IP 주소나 포트 번호 등을 서버 측에게 알려준다. 이후, 데이터 송/수신 시 데이터를 저장할 버퍼가 필요한데, 이를 '버퍼 메모리'라고 하며 이에 대한 메모리 할당 역시 접속 단계에서 일어난다.

 

여기서 데이터 송/수신을 위해 어떤 데이터가 필요할까?

아래는 TCP 헤더에 들어가는 필드 정보이다.

필드 명칭	길이(비트)	설명
송신처 포트 번호	16	이 패킷을 송신한 측의 프로그램의 포트 번호
수신처 포트 번호	16	이 패킷을 받는 상대 프로그램의 포트 번호
시퀀스 번호 (송신 데이터의 일련 번호)	32	이 패킷의 맨 앞 위치의 데이터가 송신 데이터의 몇 번째 바이트에 해당하는지 송신측에서 수신측에 전달하기 위한 것
ACK 번호 (수신 데이터의 일련 번호)	32	데이터가 몇 바이트까지 수신측에 도착했는지를 수신측에서 송신측에 전달하기 위한 것.  ACK는 acknowledge의 약자로, '아크'라고 읽습니다.
데이터 오프셋	4	데이터 부분이 어디부터 시작하는지를 나타낸다. 헤더의 길이를 나타낸다.
사용하지 않음	6	현재 사용하지 않는 헤더
컨트롤 비트	6	각 비트가 각각 통신 제어상의 의미를 가진다. - URG: 긴급 포인터의 필드가 유효하다는 것. - ACK : 수신 데이터의 일련번호 필드가 유효하다는 것을 나타낸다. 보통 데이터가 올바르게 수신측에 도착한 것을 의미한다. - PSH: flush 동작에 의해 송신된 데이터 - RST: 접속을 강제로 종료하고 이상 종료 시 사용한다. - SYN: 송신측과 수신측에서 일련번호를 서로 확인한다. 이걸로 접속 동작을 나타낸다. - FIN: 연결 끈힉를 나타낸다.
윈도우	16	수신측에서 송신측에 윈도우 사이즈 (수신 확인을 기다리지 않고 묶어서 송신할 수 있는 데이터 양)를 통지하기 위해 사용한다.
체크섬	16	오류 유무 검사
긴급 포인터	16	긴급하게 처리해야 할 데이터의 위치
옵션	가변 길이	위의 헤더 필드 이외의 제어 정보를 기록하기 위해, 헤더에 옵션 필드를 추가할 수 있다. 그러나 접속 동작을 제외하면 옵션 필드를 사용하는 예가 적다.

 

위의 항목은 고정이 되어 있기 때문에, 접속이나 송/수신, 연결 끊기의 각 단계에서 클라이언트와 서버가 대화할 때마다 이 제어 정보를 부가한다. (패킷의 맨 앞부분에 부가한다는 것)

아직은 접속을 하는 단계이기 때문에 패킷 내용에는 제어 정보만 있으며, 이 제어 정보를 맨 앞부분에 배치하는 곳부터 '헤더'라고 말한다.

그리고 여기서 사용하는 헤더의 경우 TCP 헤더라고 말한다.

 

참고로 패킷 전체는 '하나의 데이터 조각'의 구성 요소를 의미한 것이다.

 

위의 모습은 클라이언트와 서버 사이에 주고받는 제어 정보이며, 데이터를 저장한 패킷의 모습이다. 

만약 제어 동작이나 연결 끊기 동작에서는 애플리케이션의 데이터가 없다면 제어 정보만 주고받았을 텐데, 이때는 데이터 조각이 빠진다.

프로토콜 스택은 내부에 저장된 애플리케이션에서 통지된 정보나 통신 상대로부터 받은 정보, 진행 상황 등을 참고하면서 움직인다. 그래서 소켓의 제어 정보는 프로토콜 스택의 프로그램과 일체화 되어 있다고 말할 수도 있다. (사실 프로토콜을 만드는 사람에게 달려있다)

또한, 소켓에 기록한 제어 정보는 상대측에서 볼 수 없다. 규칙에 따라 헤더에 기록된 제어 정보로도 클라이언트와 서버가 서로 연락을 취하기 때문이다.

통신 동작에 이용되는 제어 정보
- 헤더에 기입되는 정보
- 소켓 (프로토콜 스택의 메모리 영역)에 기록되는 정보

 

자, 다시 돌아가서 connect() 메서드를 호출하는 시점을 생각해보자.

이때 서버측의 IP 주소와 포트 번호를 쓰면 명령이 프로토콜 스택의 TCP 쪽으로 전달된다.

전달된 TCP는 서버의 TCP와 제어 정보를 주고 받는데, 먼저 제어 정보를 기록한 헤더를 만든다.

 

아까 위에서 작성한 표 중에서 '송신처'와 '수신처'의 '포트번호' 정보가 헤더에 있던 걸 볼 수 있는데, 이 2가지의 정보를 통해서 클라이언트와 서버 측의 소켓을 지정하여 어떤 소켓으로 접속해야 할지 판단할 수 있다.

판단한 이후에는 컨트롤 비트인 'SYN' 비트를 1로 만드는데, 이렇게 만든 헤더를 IP에게 건네준다.

 

그리고 마찬가지로 IP에서도 어떠한 동작을 하고, 서버에 도착하면 서버 측의 IP가 이를 받고, 다시 서버 측의 TCP가 받는다.

서버 측의 TCP는 헤더 정보를 바탕으로 수신처의 소켓을 찾아내고, 해당 소켓에게 진행 중이라고 응답한다.

서버에서도 동일하게 송/수신처의 포트 번호와 SYN=1인 헤더를 만들고, 추가적으로 'ACK'라는 비트도 1로 만든다. (클라이언트에서는 0이었음) 이렇게 만든 헤더를 IP에게 주고, 또 다시 클라이언트의 IP -> TCP로 가는 것이다.

 

클라이언트는 다시 TCP 헤더를 조사하여 접속 동작이 성공했는지 확인하고, SYN이 1이면 소켓에 접속 완료에 대한 정보를 기록하고, 마찬가지로 패킷이 도착한 것을 서버에게 알리기 위해서 ACK 비트를 1로 만든 TCP 헤더를 반송한다.

위와 같은 방식으로 이루어졌다고 보면 된다.

결과적으로 '커넥션'을 유지하면서 close를 통해 연결을 끊을 때까지 계속 유지되며, 커넥션이 완료되면 프로토콜 스택의 접속 동작이 끝나기 때문에 connect의 실행이 끝나면서 애플리케이션을 제어할 수 있게 된다.

 

---

✔️ 데이터 송/수신하기

이제 이 부분에 대해서 한 번 알아보도록 하자.

write를 호출하여 송신 데이터를 먼저 프로토콜 스택에 건네준다. 

이를 받은 프로토콜 스택은 다음과 같은 특징을 가진다.

 

 

🌱 1. 받은 데이터 내용을 알 수 없다.

write를 호출할 때 송신 데이터의 길이를 지정하지만, 프로토콜 스택은 해당 길이만큼 바이너리 데이터가 1바이트씩 나열되어 있다고만 인식한다. 기본적으로 프로토콜은 받은 데이터를 '송신용 버퍼 메모리 영역'에 저장한다.

 

왜냐하면, 송신을 의뢰할 때 애플리케이션에서 프로토콜 스택에 건네주는 데이터 길이는 애플리케이션에 따라 다르기 때문이다. 프로토콜에서 제어할 수 없으니 데이터를 우선 저장하고 나서, 애플리케이션에 따라 동작을 하는 것이다.

판단할 수 있는 기준은 크게 2가지로 나뉘는데, 하나는 '한 패킷에 저장할 수 있는 데이터의 크기', 하나는 '타이밍' 이다.

 

f프로토콜은 기본적으로 MTU (Maximum Transmission Unit)를 바탕으로 판단하는데, 패킷의 맨 앞 부분에 헤더가 포함되어 있기 때문에 헤더 정보를 제외한 것을 MSS (Maximum Segment Size)라고 한다. 애플리케이션에서 받은 데이터가 MSS에 도달할 때까지 데이터를 저장하고 송신 동작을 하면 패킷이 나누어질 걱정을 할 필요는 없다. 만약, 송신 속도가 느려지는 경우 MSS에 가깝게 저장하면 저장하는데 걸리는 시간으로 인해 송신 동작이 지연되기 때문에 내부의 타이머를 통해 일정 시간이 경과하면 패킷을 송신한다.

 

💬 MSS를 중시하면 패킷 길이가 길어지기 때문에 네트워크 효율이 높아지지만, 버퍼에 머무는 시간만큼 송신 동작이 지연된다.
반대로 타이밍을 중시하게 되면 지연은 줄어들지만, 효율이 떨어지기 때문에 프로토콜 스택 개발자가 잘 절충해야 한다.

- 물론, 이렇게 프로토콜 스택에만 전부 맡길 수 없기 때문에 애플리케이션 측에서 송신의 타이밍을 제어하는 여지도 남겨두었다. 데이터 송신을 의뢰할 때 옵션을 지정할 수 있으며, 버퍼에 저장 없이 바로 송신하도록 하면 프로토콜 스택은 바로 송신이 가능하다.

 

---

🌱 2. 데이터가 크면 분할한다.

HTTP 리퀘스트 메시지는 별로 안 길지만, 폼데이터 같은 경우에는 되게 길다.

이러면 MSS의 길이를 초과하기 때문에 크기에 맞게 분할하고, 분할한 조각을 한 개씩 패킷에 넣어 송신해야 한다.

요런 식으로 쪼개어서 넣는다

송신 버퍼에 저장된 데이터는 MSS 길이를 초과하기 때문에 다음 데이터를 기다릴 필요가 없다.

그냥 송신 버퍼의 데이터를 맨 앞부터 MSS에 맞게 분할하고, 분할된 조각을 한 개씩 패킷에 넣어 송신한다.

이렇게 송신한 데이터 맨 앞에 TCP 헤더를 부가하고, 소켓에 기록된 제어 정보를 바탕으로 송신/수신처 포트 번호 등 필요한 항목을 부가한 다음 IP에 건네주어 송신 동작을 수행한다.

 

---

 

🌱 3. ACK 번호를 사용하여 패킷이 도착했는지 확인한다

TCP의 경우 송신한 패킷이 상대에게 도착했는지 확인하고, 도착하지 않았다면 다시 송신하는 기능이 있다.

 

우선, 기본적으로 어떻게 확인하는지 알아보자.

TCP는 데이터를 조각으로 분할할 때 각 조각이 몇 번째 바이트에 해당하는지 세어둔다.

그리고 데이터 조각을 송신할 때 세어둔 값을 TCP 헤더에 기록하는데, '시퀀스 번호'라는 항목이 해당된다.

송신하는 데이터 크기도 수신측에 전달하지만, 패킷의 전체 길이에서 헤더 길이를 빼면 데이터의 크기를 계산할 수 있기 때문에 따로 헤더이 기록하지는 않는다. 

 

특히, 이렇게 계산하는 과정에서 수신측은 패킷의 누락도 확인할 수 있다. 

만약 1460 바이트까지 수신을 완료한 상태에서, 시퀀스 번호가 1461이라면 패킷 누락이 없는 것이겠지만, 시퀀스 번화 1461이 도착도 안 했는데 2921인 패키싱 도착했다면 누락된 것을 유추해낼 수 있게 된다.

 

만약, 누락이 없다면 수신측은 그 이전에 수신한 데이터와 합쳐서 데이터를 몇 번째 바이트까지 수신한 것인지 계산하고, 그 값을 TCP 헤더의 ACK 번호에 기록하여 송신측에게 알려준다.

 

시퀀스 번호는 1이 아닌 난수를 초기값으로 삼는다. 1부터 시작한다고 정해졌다면 악의적인 공격을 할 수 있기 때문이다.

하지만 몇 번째 초기값인지 알 수 없다는 문제가 생기기 때문에 초기값은 송/수신 전에 미리 알려준다.

위의 그림에서 SYN=1을 전송했던 그림이 떠오를 것이다. 거기서 SYN=1로 서버에게 보낼 때 초기값을 통지한다.

 

 

💬 그렇다면, 만약 양방향으로 통신할 때는 괜찮을까?

지금까지 단방향으로 데이터를 보낼 때만 고려했었다. 

하지만, TCP의 데이터 송/수신은 양방향이기 때문에 이에 대해서도 고려해야 한다.

 

네모는 접속 동작과 송/수신 동작의 구분이다.

 

먼저, 클라이언트 -> 서버로 보내는 시퀀스 번호는 클라이언트에서 산출하여 데이터와 함께 서버에게 통지한다.

이것이 통과하면 서버측에서는 ACK 번호를 산출하여 클라이언트에게 반송한다.

반대로, 서버 -> 클라이언트에 보내는 시퀀스 번호는 서버측에서 산출하여 클라이언트에 통지하고, 이것이 도착하면 클라이언트 측은 이를 받아 ACK 번호를 산출하여 서버에 반송한다. 

이렇게 초기값도 양쪽에서, 접속 동작을 할 때도 서로 통지하게 된다.

 

자, 그러면 실제로 어떻게 움직이는지 살펴보자.

1. 클라이언트 -> 서버로 보내는 데이터에 대한 시퀀스 번호의 초기값을 클라이언트에서 산출 후, 서버에 통지
2. 서버는 받은 초기값으로부터 ACK 번호를 산출 후 클라이언트에 반송
3. 서버 역시 클라이언트에 보내는 데이터에 관한 시퀀스 번호의 초기값을 산출하여 클라이언트에게 함께 통지
4. 클라이언트도 받은 초기값으로부터 ACK 번호 산출 후 서버에게 반송
5. (기존은 양방향이지만 웹의 경우) 최초로 클라이언트에서 서버로 메시지를 보내고, 데이터와 함께 시퀀스 번호 전송
6. 서버는 데이터를 받아 ACK 번호 반송 (만약 서버에서 클라이언트에게 보낸다면 5, 6의 화살표 방향 변경)

TCP 역시 이러한 방법으로 상대가 데이터를 받은 것을 확인하며, 확인할 때까지 송신한 패킷을 송신용 버퍼 메모리에 보관한다.

만약 송신한 데이터에 대한 ACK 번호가 상대로부터 오지 않으면 패킷을 재전송한다.

 

⭐️ 위의 구조는 패킷이 올바르게 도착하지 않았다면 다시 보내기 때문에, 오류가 발생하더라도 회복이 가능하다.

또한, 이곳에서 회복 처리가 가능하기 때문에 LAN 어댑터나 버퍼, 라우터 모두 회복 조치를 취할 필요가 없다.

그저 오류가 발생했다면 패킷을 버리기만 하면 된다.

- 참고로, 케이블 분리나 서버 다운 같은 경우 몇 번이나 재전송을 하더라도 유실되기 때문에 그때는 강제로 종료하고 애플리케이션에 오류를 통지한다.

 

---

 

🌱 4. 패킷 평균 왕복 시간으로 ACK 번호의 대기 시간을 조정한다.

💬 타임아웃: ACK 번호가 돌아오길 기다리는 시간.

 

보통 ACK 번호가 지연되는 경우는 혼잡할 때가 많기 때문에, 번호가 오지 않는다고 무작정 패킷을 전송하면 오히려 상황을 악화시킬 수 있다. 그래서 타임아웃 시간은 적절한 값으로 설정해야 한다.

TCP의 경우 대기 시간을 동적으로 변경하고 있으며, ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단한다. 데이터 송신 시 ACK 번호가 돌아오는 시간을 항상 측정해두고, 그에 따라 대기 시간을 변화시키고 있다. (최소는 0.5~1초)

 

---

 

🌱 5. 윈도우 제어 방식을 통해 효율적으로 ACK 번호를 관리한다.

💬 윈도우 제어: 한 개의 패킷을 보낸 후, ACK 번호를 기다리지 않고 차례로 연속된 패킷을 보내는 방법

 

ACK 번호가 돌아올 때까지 아무 일도 안 하는 거는 매우 낭비다.

TCP는 ACK 번호가 돌아올 때까지 '윈도우 제어'라는 방식을 통해 송신도 함께 진행한다.

 

하지만, 이 경우 문제가 있다.

수신측의 TCP의 경우 일단 패킷을 받으면 이를 수신용 버퍼 메모리에 보관한다.

기존 같았으면 수신측은 ACK 번호를 계산하거나 조각을 연결하여 데이터를 복원한 다음! 애플리케이션에게 건네주어야 하니까 다음 패킷이 와도 수신 버퍼를 설치하고 보관한다.

하지만, 애플리케이션에 건네주는 속도보다 빠른 속도로 패킷이 오게 되면 수신 버퍼는 넘치고 만다. 

그래서 수신측에서 송신측에 수신 가능한 데이터 양을 통지하고, 수신측은 이 양을 통지하지 않도록 송신 동작을 실행한다.

 

⭐️ 수신측은 수신 버퍼에 데이터를 임시 보관하고, 수신 처리를 진행한다.
- 수신 처리가 끝나고 버퍼에 빈 공간이 생기면 그 분량만큼 수신할 수 있는 데이터 양을 늘린다!
그리고, 이를 TCP 헤더의 '윈도우 필드'에서 송신측에 알린다.

수신 가능한 데이터 양의 최대값을 '윈도우 사이즈'라고 하며, TCP를 정밀 조정하는 매개 변수 중 하나이다.

 

---

 

🌱 6. ACK 번호와 윈도우를 합승한다.

수신 데이터가 수신 버퍼에 통지된다면, 윈도우를 하나하나 수신측에 통지할 필요는 없다.

윈도우 값은 송신측이 데이터를 송신할 때마다 본인이 보낸 데이터만큼 감산하여 스스로 산출할 수 있기 때문이다.

 

윈도우 통지가 필요한 것은, 수신측이 수신 버퍼에서 데이터를 추출하여 애플리케이션에게 건네주었을 때이다.

이 동작은 수신측이 애플리케이션에서 먼저 의뢰를 해야 하기 때문에, 언제 일어날지 송신 측에서는 알 수가 없다. 그래서 수신측에서 애플리케이션에 데이터를 건네주고, 수신 버퍼의 빈 영역이 늘어났을 때 송신 측에 통지를 해야 하는데, 이것이 윈도우 통지의 타이밍이다.

ACK 번호 역시 수신 측에서 데이터를 받고 나서, 정상적으로 수신이 가능하면 보낸다.

 

결과적으로, 송신측에서 데이터를 보내고, 그게 '정상적으로 도착했을 때' ACK 번호를 송신측에 통지하고, 데이터를 애플리케이션에 건네주었을 때 윈도우를 송신측에 통지하게 된다.

= 데이터의 패킷을 받을 때마다 ACK 번호도 보내고, 윈도우 통지도 보내는 것이다.

= 효율성이 매우 낮다.

 

그래서 소켓을 바로 보내지 않고 잠시 기다렸다가, 그 사이 통지 동작이 일어나면 한 개의 패킷으로 묶어서 보낸다.

혹은, ACK 번호나 윈도우 통지가 연속해서 일어난다면 가장 마지막 통지만 보내서 보내는 패킷의 양을 줄인다.

 

---

 

🌱 7. HTTP 응답 메시지 수신하기

이제 프로토콜 스택이 HTTP 리퀘스트 메시지를 보내는 동작은 끝났다.

하지만, 이렇게 메시지를 보내면 웹 서버에서 응답 메시지가 오기를 기다렸다가 오면 이를 받는다.

 

여기서는 짧게 말하자면, 브라우저는 리퀘스트 메시지를 송신해달라고 의뢰하고, 서버에서 돌아오는 응답 메시지를 받기 위해 read()를 호출한다. 그러면 프로토콜 스택으로 다시 제어가 넘어간다.

 

그리고 수신 버퍼에서 수신 데이터를 추출하여 애플리케이션에 건네준다.

만약 응답 메시지가 아직 돌아오지 않았다면 수신 버퍼에서 수신 데이터를 추출하는 일을 잠시 보류한다.

그리고, 서버에서 응답 메시지의 패킷이 도착했을 때 이를 수신하여 다시 애플리케이션에 건네준다.

 

사실 송신이랑 거의 비슷하다. 간단히 읽어보고 마무리하자.

수신한 데이터 조각 + TCP 헤더를 보고 데이터 누락 검사 > 완전하면 ACK 반송 > 데이터 조각을 수신 버퍼에 일시적으로 보관 > 조각을 연결하여 데이터 복원 > 애플리케이션이 지정한 메모리 영역으로 기록해주고 > 애플리케이션에게 제어 건네주기 > 그리고 타이밍을 가늠하여 윈도우를 송신측에 통지!

 

---

✔️ 데이터 전송 후 연결 끊기

마지막으로 어떻게 소켓을 말소하는지 알아보자.

송/수신 동작이 종료되어야 연결 끊기 과정으로 들어가는데, 만약 웹 브라우저라면 웹 서버에 리퀘스트 메시지를 보내고, 서버에 이에 대해 응답 메시지를 보내면 데이터 보내기가 완료되어 연결 끊기 단계에 들어갈 수 있다. 클라이언트 측에서 먼저 연결 끊기를 하는 애플리케이션이라면, 반대로 클라이언트에서 먼저 종료할 것이다.

 

서버 측에서 먼저 연결을 끊는다고 가정해보자.

7. 서버에서 컨트롤 비트인 FIN 비트에 1을 설정하여 IP에게 의뢰한다.
8. 클라이언트측의 프로토콜 스택은 이를 받아 연결 끊기 도작에 들어갔다는 것을 기록하고, ACK 번호를 서버측에 반송한다.
이것이 끝나면 애플리케이션이 데이터를 가지러 올 때까지 기다린다. (만약 클라이언트 측이 먼저 끊는다면 7, 8번의 화살표 방향은 반대가 된다)
9. 클라이언트 역시 FIN = 1을 설정하여 IP를 의뢰한다.
10. 서버에서는 이를 받아 기록 후 ACK 번호를 클라이언트에게 반송한다.

 

이후, 애플리케이션이 read를 호출하여 데이터를 가지러 온다면 데이터 대신에 서버에서 보낸 데이터를 전부 수신 완료했다는 사실을 클라이언트 측의 애플리케이션 (=브라우저)에게 알린다. 서버에서 보낸 데이터를 전부 수신 완료했을 때 클라이언트도 종료된다.

 

💬 FIN=1로 설정한 패킷이 도착하기 전에, 송신 측 애플리케이션에서 데이터를 생성하고 송신 버퍼에 저장해둘 수 있는데, 이때는 데이터를 건내주는 작업이 보류되었기 때문에 read를 호출하여 데이터를 가지러 왔을 때 남은 데이터를 함께 건네준다.

 

이후, 클라이언트측의 애플리케이션 역시 close를 호출하여 데이터 송/수신의 동작을 종료하고, 프로토콜 스택도 마찬가지로 FIN=1을 설정한 TCP 헤더를 만들고 IP에 의뢰하여 서버에 송신한 다음, ACK 번호가 돌아오면 종료한다.

 

---

✔️ 소켓 말소하기

정말 마지막 단계이다. 소켓을 말소하는 단계지만, 중요한 건 바로 말소시키는 게 아니라 잠시 대기했다가 말소한다는 것이다.

이는 오동작을 막기 위해서인데, 대표적인 오동작 중 하나를 살펴보자.

이번에는 클라이언트가 먼저 연결 끊기를 했다고 가정해보자.

 

1. 클라이언트는 FIN=1 송신
2. 서버는 이를 받아 ACK 번호 송신
3. 서버는 FIN=1 송신
4. 클라이언트는 이를 받아 ACK 번호 송신

이때, 만약 마지막으로 클라이언트가 보낸 ACK 번호가 돌아오지 않아서 다시 FIN을 보내려고 하는데, 클라이언트의 소켓이 없어졌다면 어떻게 해야 할까? 소켓이 없어지면 내부에 있는 제어 정보 (송/수신측의 포트번호 등등)도 사라지기 때문에, 어떤 것으로 보내야 할지 알 수 없다.

또한, 만약 새로운 소켓이 그 사이에 생성되어 그전에 클라이언트와 사용했던 소켓과 동일한 포트 번호가 할당된다면?

그러면 새로운 소켓의 클라이언트는 서버의 FIN을 받아서 바로 연결이 끊어질 수도 있게 된다.

 

패킷이 없어졌을 때 다시 보내는 동작은 보통 몇 분쯤 계속되고, 어느 정도 지났을 때 회복 전망이 없다고 판단하고 보내는 걸 멈춘다.

명확한 규정은 없지만, 보통 몇 분... 정도 기다리고 나서 소켓을 말소한다.