기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

---

머리말

TCP 프로토콜은 연결, 신뢰성 있는 전송, 바이트 스트림 지향, 전이중 등의 특성을 가지고 있습니다. 신뢰성 있는 전송이 핵심 부분입니다.

---

1. TCP 헤더 구조

그림 1

위 그림은 TCP 헤더의 구조이다.
(1) 원본 포트와 대상 포트는 너무 많이 소개할 필요가 없습니다. 송신측과 수신측을 표시하는 데 사용되는 프로그램입니다.
(2) 시퀀스 번호와 확인 시퀀스 번호는 나중에 소개되는 TCP의 확인 응답 메커니즘에 사용됩니다.
(3) 여기서 데이터 오프셋 부분의 4비트는 실제로 TCP 헤더의 길이를 나타내는데 사용된다. 4비트이기 때문에 표현되는 최대 개수는 15개이지만, 단위가 4바이트이기 때문에 헤더의 최대 길이가 된다. TCP 헤더는 60바이트입니다.
(4) UDP 데이터 패킷의 최대 길이는 64kb로 매우 제한적이라는 것을 우리 모두 알고 있으므로 이러한 상황을 피하기 위해 TCP 기능이 확장되면 나중에 사용할 수 있도록 TCP 헤더에 6개의 예약된 비트가 제공됩니다. 예약된 비트를 사용합니다.
(5) 6바이트 영어 식별자는 나중에 소개되는 TCP 메커니즘과 관련되므로 여기서는 소개하지 않습니다.
(6) 체크섬은 UDP의 체크섬과 동일한 기능을 가지며 전송 과정에서 데이터가 변경되었는지 여부를 확인하는 데에도 사용됩니다.
(7) 창에 대해서는 나중에 메커니즘을 소개할 때 논의하겠습니다.
(8) 비상 포인터는 추후 소개될 예정입니다.
(9) 옵션 중에는 선택/선택 옵션이 있습니다.

2. TCP의 10가지 핵심 메커니즘

2.1 확인 응답

TCP 프로토콜은 매우 중요한 문제인 안정적인 전송을 해결해야 합니다. 소위 신뢰할 수 있는 전송은 보낸 사람이 받는 사람에게 100% 데이터를 보낼 수 있다는 것을 의미하지는 않지만, 받는 사람이 알고 있는지 여부를 보낸 사람에게 알릴 수 있도록 최선을 다합니다.
그림 2

그림 2에서 볼 수 있듯이 여신에게 메시지를 보낼 때마다 여신이 다시 메시지를 보냅니다. 이는 클라이언트가 데이터 패킷을 보내고 서버가 응답하는 것과 같습니다. 이때 응답 데이터 패킷은 그림 1의 ACK 플래그가 1로 설정됩니다.
이미지 3

그림 3에서 볼 수 있듯이 여신에게 여러 메시지를 보낼 때 여신은 메시지에 서로 다른 속도로 응답하기 때문에 우리는 여신이 내 여자친구가 되는 데 동의했다고 생각하기 쉽습니다. 여신님은 길을 잃으라고 하십니다. 이것이 인터넷에 객관적으로 존재하는 선착순 문제입니다. 분명히 여러 데이터 패킷을 클라이언트에 보내고 클라이언트가 여러 응답 데이터 패킷에 응답하는 경우 어떤 응답이 어떤 데이터 패킷이 전송되었는지 구별해야 합니다. 이 문제는 그림 1의 시퀀스 번호와 확인 시퀀스 번호를 사용하여 해결할 수 있습니다. .

전송된 각 데이터 패킷에는 시퀀스 번호가 있지만 확인 시퀀스 번호가 없거나 이에 응답한 데이터 패킷의 ACK가 유효하지 않습니다. 이때 확인 시퀀스 번호 필드는 유효합니다. 그리고 송신된 데이터 패킷 순서 번호와 응답 데이터 패킷의 확인 순서 번호가 일치하므로 누가 누구에게 응답했는지 식별할 수 있으며 위에서 언급한 네트워크의 선착순 문제를 해결할 수 있습니다. .
실제 TCP 데이터 패킷의 시퀀스 번호는 바이트에 따라 번호가 지정됩니다. 각 바이트에는 시퀀스 번호가 할당됩니다. TCP 헤더의 시퀀스 번호 값은 페이로드의 첫 번째 바이트 번호입니다. 페이로드 부분의 첫 번째 바이트의 바이트 번호가 1이고 페이로드 길이가 1000바이트인 경우 데이터 패킷의 응답 데이터 패킷 헤더에 있는 승인 시퀀스 번호는 1001입니다. 해당 데이터 패킷에 해당하는 응답 데이터 패킷은 페이로드의 마지막 바이트 수가 1씩 증가하도록 설정됩니다. 실제로 1001을 반환한다는 것은 전송된 1000바이트 페이로드를 수신했다는 의미로 이해하기 쉽습니다. 그림 4와 같이 1001 이후의 데이터가 요청됩니다.
그림 4

이후에 전송되는 데이터 패킷의 경우 시퀀스 번호가 증가하는데, 주의할 점은 시퀀스 번호가 증가하더라도 시퀀스 번호는 0이나 1에서 시작하지 않는다는 점입니다.
안정적인 전송은 주로 "확인 응답" 메커니즘을 사용하여 달성할 수 있습니다. 모든 것이 잘 진행되고 있는지, 패킷 손실이 발생했는지 여부를 응답 메시지를 통해 보낸 사람에게 알릴 수 있습니다. 패킷 손실(전송 과정에서 데이터가 삭제되어 반대쪽에 도달할 수 없는 객관적인 무작위 이벤트)이 발생하면 어떻게 해야 합니까?

2.2 타임아웃 재전송

시간 초과 재전송은 네트워크의 패킷 손실 문제를 처리하는 데 사용됩니다.
여기에는 주로 두 가지 상황이 있습니다.
(1) 전송된 데이터 패킷이 손실되었습니다.

이때, B는 A의 데이터 패킷을 수신하지 못하면 응답 패킷을 보내지 않는다. A가 기다리고 있는 이벤트가 일정 임계값을 초과하면 패킷 손실 문제가 발생한 것으로 판단하고 데이터 패킷을 다시 전송한다.
(2) 응답 데이터 패킷이 손실되었습니다.

A가 응답 데이터 패킷을 수신하지 못한 경우에도 데이터 패킷을 재전송하지만 이때 B는 이미 데이터 패킷을 수신한 상태이므로 두 개의 동일한 데이터 패킷을 수신하게 됩니다. 특히 전송과 같은 반복적인 전송이 발생하는 문제의 경우 비과학적입니다.
위의 문제에 대해 TCP 수신기는 시퀀스 번호에 따라 수신된 데이터의 중복을 제거합니다. TCP 계층은 중복 문제에 신경 쓰지 않습니다. 핵심은 애플리케이션 계층이 중복 데이터를 읽을 수 없다는 것입니다. 재전송 횟수에 관계없이 애플리케이션 계층은 데이터의 복사본을 하나만 읽도록 해야 합니다.
수신 운영 체제의 커널에는 데이터 구조(수신 버퍼)가 있습니다. 이 데이터 구조는 B가 데이터 패킷을 수신하고 여러 계층을 거쳐 전송 계층으로 전달될 때 발생합니다. 데이터를 넣기 위해 블로킹 큐를 입력하면 큐는 데이터 패킷의 시퀀스 번호를 기준으로 데이터가 존재하는지 여부를 판단합니다. 존재한다는 것은 동일한 데이터 패킷이 수신되어 한 번 읽혔다는 것을 의미합니다. 응용 프로그램 계층), 직접 삭제됩니다. 수신 버퍼의 또 다른 점은 네트워크의 후순위 문제를 해결할 수 있다는 것입니다. 전송된 데이터는 시퀀스 번호에 따라 정렬된 다음 애플리케이션 계층 프로그램에서 순서대로 소비됩니다.

위 그림과 같이 수신 버퍼에 도착하는 데이터는 순서 번호에 따라 정렬됩니다. 이는 마지막 전송 선착순 문제를 해결할 뿐만 아니라 이때 중복되는 데이터 패킷을 수신하는 문제도 해결합니다. 재전송된 데이터 패킷의 일련 번호가 500인 경우 수신 버퍼의 최소 시퀀스 번호가 1000이므로 응용 프로그램에서 이미 500을 읽었으므로 바로 폐기됩니다.
패킷 손실 자체는 작은 확률의 이벤트입니다. 패킷 손실 수가 증가하면 네트워크에 큰 문제가 됩니다. 재전송 횟수가 증가할수록 재전송 사이의 시간 간격이 계속해서 길어집니다. 재전송이 많아지면 네트워크에 문제가 있음을 의미하고 재전송을 자주 수행하면 리소스가 소모되기 때문입니다. 재전송 횟수가 임계값에 도달하면 RST 플래그 비트가 1로 설정된 재설정 메시지가 전송되어 양쪽 끝의 중간 상태를 해제합니다. 재설정 메시지에 응답하지 않으면 양쪽 끝의 연결이 삭제됩니다.
시간 초과 재전송은 승인 응답을 보완합니다.

2.3 연결 관리

2.3.1 연결 설정: 3방향 핸드셰이크

그림 5

연결을 설정한다는 것은 두 통신 당사자가 상대방의 정보를 저장한다는 것을 의미합니다. 특정 완료에는 그림 5와 같이 세 가지 네트워크 상호 작용이 필요합니다.
3방향 핸드셰이크는 클라이언트가 처음 시작해야 합니다. 3방향 핸드셰이크를 시작하는 사람이 바로 클라이언트입니다. 구체적인 프로세스는 그림 5와 같습니다. 먼저 클라이언트는 SYN 패킷을 보냅니다. 즉, 헤더의 SYN 플래그가 1로 설정됩니다. 그런 다음 서버는 응답 패킷을 반환합니다. 응답 패킷의 ACK 및 SYN 플래그는 다음과 같습니다. 둘 다 1로 설정됩니다. ACK와 SYN 플래그 비트가 포함된 데이터 패킷이 운영 체제 커널에 의해 동시에 전송되므로 함께 전송되어 성능을 향상시킬 수 있기 때문입니다. 마지막으로 클라이언트는 서버에 응답 패킷을 전송하고 3방향 핸드셰이크가 완료됩니다. 이 프로세스 중에 전송되는 데이터 패킷에는 비즈니스 데이터가 포함되어 있지 않습니다.
삼자 악수의 의미는 다음과 같습니다.
(1) 돌을 던져 길을 묻는다
통신 링크가 원활한지 확인
(2) 몇 가지 중요한 매개변수를 협상합니다.
예를 들어, 전송된 데이터 패킷의 시퀀스 번호
(3) 양 당사자의 수신 및 전송 능력을 확인하십시오.
왜 세 번의 악수를 해야 할까요? 네 번의 악수 또는 두 번의 악수가 괜찮습니까?
4방향 핸드셰이크는 일반 기능에 영향을 미치지 않지만 성능을 저하시킵니다. 양방향 핸드셰이크는 서버의 수신 및 전송 기능을 완전히 확인할 수 없습니다.
또한 여기에는 두 가지 중요한 상태가 더 있습니다. 첫 번째는 수신 상태입니다. 이는 서버가 현재 포트를 바인딩하고 클라이언트가 SYN 패킷을 보내기를 기다리고 있음을 의미합니다. 이해하기 쉽고 연결이 설정된 후의 상태를 의미합니다.

2.3.2 연결 끊기: 네 번 흔드세요.

클라이언트에서만 먼저 시작할 수 있는 3방향 핸드셰이크와 달리 4방향 핸드셰이크는 서버와 클라이언트 모두에서 시작할 수 있습니다.
그림 6

4번 웨이브하는 구체적인 프로세스는 그림 6에 나와 있습니다. 클라이언트 코드에서 소켓.close() 메서드가 호출되거나 프로세스가 종료되면 서버에 FIN 종료 메시지가 전송됩니다. ACK 메시지가 돌아오지만 서버 코드가 나올 때까지 기다려야 합니다. 소켓.close()와 같은 코드를 호출한 후에만 FIN 종료 메시지를 클라이언트에 보낼 수 있습니다. 그 후 클라이언트는 서버에 ACK 메시지를 보냅니다. 네 번 흔들면 과정이 완료됩니다.
여기서 중간에 있는 ACK와 FIN은 결합될 수 없습니다. ACK는 시스템 커널에 의해 전송되므로 서버가 FIN 메시지를 받으면 즉시 전송되지만 FIN 메시지는 서버 측 코드가 실행될 때까지 기다려야 합니다. close() 이후에 전송될 수 있으며 둘 사이에는 시간차가 있습니다. 하지만 특별한 경우에는 ACK를 늦게 보내서 FIN과 함께 보낼 수도 있습니다.
또한 4가지 웨이브 프로세스에는 두 가지 상태가 있습니다. 첫 번째 상태는 수신자가 발신자의 FIN 메시지를 받은 후의 상태입니다. 이 상태는 A 상태입니다. 송신자가 수신자에게 보낸 마지막 ACK가 손실되는 것을 방지해야 하기 때문에 당사자는 수신자가 보낸 FIN을 수신한 후 수신자에게 ACK를 보낸 후 기다려야 합니다. 송신자가 이 FIN을 계속 수신할 수 있도록 하기 위해 이 상태의 시간은 일반적으로 2MSI(MSI: 양쪽 끝에서 데이터를 전송하는 최대 시간)이며 일반적으로 2분입니다.
수신자에서 많은 수의 close_wait가 발견되면 close() 메서드를 잊어버린 것입니다. 서버에서 많은 수의 time_wait가 발견되면 서버가 많은 수의 활성 TCP 연결 해제를 트리거했음을 의미합니다. 운영.

2.4 슬라이딩 윈도우

TCP는 안정적인 전송을 보장해야 하지만 동시에 가능한 한 효율적으로 데이터 전송을 완료하려고 합니다. 슬라이딩 윈도우는 효율성을 향상시키기 위한 메커니즘입니다. 이는 실제로 이를 보완하기 위한 방법인데, TCP는 신뢰성을 보장하기 위해 많은 성능을 희생하기 때문에 창을 아무리 밀어도 데이터 전송 속도는 UDP보다 빠를 수 없습니다.
그림 7

이는 그림 7과 같이 데이터 전송 과정이지만 데이터 패킷을 보내고 응답 데이터 패킷을 수신하는 과정은 여전히 ​​상대적으로 느립니다.
그림 8

그림 8에서 볼 수 있듯이 이는 슬라이딩 윈도우 메커니즘이 도입된 후입니다. 한 번에 하나의 데이터 패킷이 아닌 여러 데이터 패킷을 보내는 대신 반환된 응답 데이터 패킷의 대기 시간이 겹칩니다. ACK를 기다리지 않고 일괄적으로 전송되는 데이터의 양은 창 크기입니다.
그림 9

슬라이딩 윈도우 프로세스는 그림 9와 같습니다. 윈도우 크기가 4개 그룹이라고 가정하면 한 그룹이 ACK를 수신하면 이를 보완하기 위해 새 데이터가 전송되며 이는 슬라이딩 프로세스와 동일합니다. 보낸 사람이 3001이라는 ACK를 받았다면 1001부터 3001까지의 데이터를 받았다는 의미이므로 창이 오른쪽으로 두 칸 이동할 수 있습니다.
슬라이딩 윈도우에서 패킷 손실이 발생하면 어떻게 해야 합니까? 두 가지 상황이 있습니다.
(1) 전송된 데이터 패킷이 손실되었습니다.

전송된 데이터그램의 특정 그룹이 손실된 경우 많은 데이터 그룹을 수신자에게 일괄적으로 전송하더라도 수신된 ACK의 확인 시퀀스 번호는 발신자가 데이터그램을 재전송할 때까지 여전히 손실된 그룹의 번호입니다. 예를 들어 위 그림의 데이터그램 1001~2000은 나중에 여러 세트의 데이터가 전송되더라도 송신자가 재전송하고 수신자가 이를 수신할 때까지 1001의 ACK를 반환한 후 7001의 ACK로 응답합니다. .
(2) 응답 ACK가 손실되었습니다.

응답 ACK가 손실된 경우 다른 데이터 그룹의 ACK가 반환될 때까지 기다리면 되므로 걱정할 필요가 없습니다. 예를 들어 위 그림의 1001 ACK가 손실된 경우입니다. 2001년의 다음 ACK를 보낸 사람이 이를 수신했으므로 이전 데이터를 수신했으며, 후속 데이터의 ACK가 손실된 경우에도 마찬가지입니다.
위에서 언급한 패킷 손실 처리는 여전히 매우 효율적입니다. 데이터 패킷이 손실되면 간격을 채우고 ACK가 손실되면 무시하면 됩니다. 이러한 작업을 빠른 재전송이라고 합니다.
시간 초과 재전송과 빠른 재전송은 서로 다른 환경에서 채택되는 서로 다른 전략입니다. TCP가 소량의 데이터를 자주 전송하지 않으면 시간 초과 재전송이 트리거됩니다. 짧은 시간 내에 많은 양의 데이터를 전송해야 합니다. 빠른 재전송, 빠른 재전송은 슬라이딩 창 아래의 시간 초과 재전송 변형과 동일합니다.

2.5 흐름 제어

앞서 슬라이딩 윈도우에 대해 언급했듯이 윈도우 크기는 가변적입니다. 윈도우 크기를 변경하면 송신자의 전송 속도를 제어할 수 있으며, 윈도우가 클수록 단위 시간당 더 많은 데이터가 전송되므로 효율성이 높아집니다. 창이 작을수록 단위 시간당 더 많은 데이터가 전송됩니다. 데이터가 적을수록 효율성이 떨어집니다. 물론 일반적으로는 효율성이 최대한 높기를 바라지만, 높은 효율성을 위한 전제조건은 신뢰성을 보장하는 것입니다. 발신자가 너무 빨리 전송하고 수신자가 이를 처리할 수 없으면 보다 합리적인 접근 방식이 될 수 있습니다. 수신자가 송신자에게 전송 속도가 너무 빠르다고 알려주는 것이 "흐름 제어"입니다.

위 그림과 같이 앞서 언급한 것처럼 커널에는 데이터 구조 수신 버퍼가 있고, 수신자는 수신 버퍼에 있는 여유 공간의 크기를 윈도우 크기로 반환하게 됩니다. 이전 TCP 헤더에는 ACK를 사용하여 이 정보를 저장하고 반환하는 16비트 창 크기 필드가 있습니다. 창 크기 필드는 ACK에서만 적용됩니다.

위 그림에서 볼 수 있듯이 ACK는 흐름 제어 목적을 달성하기 위해 창 크기를 반환합니다. 창 크기가 0으로 돌아오면 보낸 사람은 비즈니스 데이터가 포함되지 않은 프로브 메시지를 주기적으로 보내 ACK를 트리거합니다. 버퍼 상태입니다.

2.6 혼잡 제어

혼잡 제어는 흐름 제어와 매우 유사하며 두 메커니즘 모두 슬라이딩 창과 쌍을 이룹니다.

위 그림에서 볼 수 있듯이 네트워크의 링크는 매우 복잡하며 링크의 모든 노드는 발신자의 속도를 제한할 수 있습니다. 혼잡 제어의 개념은 중간 구조가 아무리 복잡하더라도 전체적으로 처리한 다음 실험을 통해 가장 적절한 창 크기를 찾는 것입니다.

위 그림과 같이 혼잡 제어 과정인데, 네트워크의 혼잡 상황을 알 수 없기 때문에 먼저 상대적으로 작은 창 크기(느린 시작)로 시도해 보세요. 그러면 창 크기가 기하급수적으로 커지게 됩니다. 특정 임계값에 도달하면 선형적으로 커지기 시작하며, 창이 어느 정도 커지면 패킷 손실이 발생합니다. 이때 창 크기를 줄이는 방법에는 두 가지가 있습니다.
(1) 바로 밑으로 축소하고 슬로우 스타트의 처음으로 돌아가서 이전 과정을 반복합니다(이미 포기함)
(2) 절반으로 축소한 후 선형적으로 성장(실제 사용된 방법)
혼잡 제어는 실험을 통해 적절한 창 크기를 찾는 것입니다. 패킷 손실이 많으면 창 크기를 줄이고, 패킷 손실이 없으면 창 크기를 늘립니다.

2.7 지연된 응답

이름에서 알 수 있듯이 지연된 응답은 ACK를 반환하기 전에 잠시 기다리는 것을 의미합니다. 이는 실제로 창 크기 문제와도 관련이 있습니다. ACK의 지연된 응답은 수신자에게 수신 버퍼의 데이터를 소비하는 데 더 많은 시간을 제공하여 결과를 증가시키기 때문입니다. 여유 버퍼의 크기가 증가하면 ACK에서 반환되는 창 크기가 증가하고 발신자는 더 많은 데이터를 일괄적으로 보낼 수 있습니다.
지연 응답 방법에는 두 가지가 있습니다.
(1) 특정 시간에 따른 지연을 지정합니다.
(2) 수신된 데이터의 양에 따라
위의 두 가지 전략을 조합하여 사용합니다.

2.8 피기백 응답

피기백 응답은 실제로 전송 효율성을 향상시키는 데 사용되는 메커니즘으로 이전에 나타났습니다. Three-way Handshake에서 동일한 데이터 패킷을 사용하여 ACK와 SYN이 반환되는 경우입니다. Four Waves와 비슷한 상황도 있습니다. ACK와 FIN이 서로 다른 시간에 전송되기 때문에 피기백 응답을 할 수 없습니다. 그러나 지연된 응답을 사용하면 보낸 사람에게 그렇게 빨리 ACK를 보낼 필요가 없습니다. 두 개의 FIN과 결합될 수 있습니다. 보조 전송은 응답에 피기백하여 단일 전송으로 결합됩니다.

2.9 바이트 스트림 지향

바이트 스트림 기반은 TCP 메커니즘으로, 여기서 주목해야 할 문제는 패킷 고정 문제입니다. 이 문제는 바이트 스트림의 특성으로 인해 서로 다른 애플리케이션 계층 데이터 패킷 간의 경계를 구분할 수 없기 때문에 발생합니다. 서버는 여러 바이트를 읽을 수도 있고 1바이트도 읽을 수 있으므로 이 문제가 쉽게 발생할 수 있습니다.
위의 스티커 백 문제에 대한 두 가지 해결책이 있습니다.
(1) 구분자를 사용한다
요청 패킷에 존재하지 않는 한 모든 기호를 사용할 수 있습니다.
(2) 데이터 패킷의 길이에 동의
그러나 대부분의 경우 Java 프로그래머는 TCP를 직접 사용하지 않고 http와 같은 기성 프로토콜을 사용하거나 protobuffer 또는 dubbo와 같은 도구를 기반으로 네트워크 통신을 구현합니다. 잃어버린.

2.10 비정상적인 상황

(1) 통신의 양쪽 끝에서 한쪽 끝의 프로세스가 중단되었습니다.
운영 체제는 4개의 웨이브를 완료하고 PCB를 웨이브합니다.
(2) 특정 호스트가 종료됨(정상 프로세스)
첫 번째 가능성은 운영 체제가 4개의 웨이브를 완료한 경우입니다. 두 번째 가능성은 수신자가 FIN을 보낸 후 ACK로 응답하지 않고 여러 번 재전송한 후 일방적으로 연결을 삭제하는 것입니다. 모두 종료되므로 저장된 정보(메모리)는 자연스럽게 사라집니다.
(3) 특정 호스트의 전원 공급 장치의 전원이 꺼졌습니다.
전원이 꺼진 호스트가 서버인 경우 클라이언트가 보낸 데이터 패킷은 ACK 없이 재전송됩니다. 여러 번의 재전송 후에도 결과가 나오지 않으면 연결이 삭제됩니다.
전원이 꺼진 호스트가 클라이언트이고 서버가 오랫동안 데이터 패킷을 수신하지 못한 경우 페이로드 없이 주기적으로 하트비트 패킷을 전송하여 클라이언트가 정상이면 ACK를 트리거합니다. 그렇지 않으면 ACK를 받지 않습니다. 어떤 응답이라도 수신하고 클라이언트가 여러 번 연속해서 응답을 보내지 않으면 클라이언트가 끊긴 것으로 간주되어 연결 정보가 삭제됩니다.
또한 TCP는 하트비트 패킷을 구현하지만 이 하트비트 패킷을 통해 클라이언트가 다운되었음을 알아내는 데 몇 분 정도 걸리는 경우가 많습니다. 실제 개발에서는 하트비트 패킷이 더 높은 빈도와 짧은 주기(두 번째 수준/밀리초 수준)로 구현되며 A->B는 핑을 보내고 B->A는 퐁으로 응답합니다. .일단 장치가 멈추는 경우 문제를 빠르게 찾을 수 있습니다.
(4) 네트워크 케이블이 연결되지 않았습니다
기본적으로는 송신자가 ACK를 받지 못하면 타임아웃되어 재전송한 다음 RST를 보낸 다음 일방적으로 연결을 삭제합니다. 수신자가 데이터 패킷을 받지 못하면 하트비트 패킷을 보냅니다. ACK를 받지 못하면 단순히 하트비트 패킷을 보냅니다.

2.11 보충

TCP 헤더 구조에는 언급되지 않은 두 개의 플래그 비트, 즉 PSH와 URG가 상대방에게 가능한 한 빨리 응답을 반환하도록 촉구합니다. URG는 TCP 패킷 헤더의 긴급 포인터 필드와 연관되어 있으며 TCP 대역 외 데이터 전송을 제어하는 ​​데 함께 사용됩니다.
대역 외 데이터 전송은 비즈니스 데이터 외에도 TCP 자체의 작동 메커니즘을 제어하는 ​​데 사용되는 특수 데이터 패킷이 있음을 의미합니다.