[휴커대학교 선생님] 컴퓨터 네트워크 강의 노트 5장 (컴퓨터 네트워크 전송 계층)

목차

5.1 전송 계층 개요

개념

프로세스 간 통신

프로세스 간 통신 프로세스

요약하다

5.2 전송 계층 포트 번호, 다중화 및 역다중화 개념

포트 번호를 사용하는 이유는 무엇입니까?

송신 측 다중화 및 수신 측 다중화

편집하다

편집하다

전송 계층 전송 프로세스

5.3 UDP와 TCP 비교

개념

사용자 데이터그램 프로토콜 UDP(사용자 데이터그램 프로토콜)

전송 제어 프로토콜 TCP(전송 제어 프로토콜)

요약하다

5.4 TCP 흐름 제어

개념

요약하다

5.5 TCP 혼잡 제어

개념

네트워크 정체를 일으키는 요인

혼잡 제어의 일반 원칙

개방 루프 제어 및 폐쇄 루프 제어

네트워크 정체 모니터링

혼잡제어 알고리즘

느린 시작 및 혼잡 회피

느린 시작

혼잡 회피

두 알고리즘의 완전한 개략도

빠른 재전송 및 빠른 복구

빠른 재전송(빠른 재전송)

빠른 복구

개선된 전체 알고리즘의 개략도

5.6 TCP 타임아웃 재전송 시간 선택

RFC6298에서는 다음 공식을 사용하여 제한 시간 재전송 시간 RTO를 계산할 것을 권장합니다.

왕복 시간 RTT 측정이 더 복잡합니다.

TCP 시간 초과 재전송 계산

요약하다

5.7 TCP 신뢰성 전송 구현

5.8 TCP 전송 연결 관리

개념

TCP 연결 설정

TCP 연결 설정은 다음 세 가지 문제를 해결해야 합니다.

TCP는 "3-패킷 핸드셰이크"를 사용하여 연결을 설정합니다.

요약하다

TCP 연결 해제

TCP는 "4개의 메시지 웨이브"를 통해 연결을 해제합니다.

TCP keepalive 타이머의 역할

5.9 TCP 세그먼트의 헤더 형식

각 분야의 역할

5.1 전송 계층 개요

개념

프로세스 간 통신

통신 및 정보처리 측면에서 볼 때, 전송 계층은 상위 애플리케이션 계층에 통신 서비스를 제공하는 계층으로, 통신 지향 부분의 최상위 계층에 속하며, 사용자 기능 중 최하위 계층이기도 하다 .
네트워크의 Edge 부분에 있는 두 호스트가 End-to-End 통신을 위해 네트워크의 Core 부분의 기능을 사용하는 경우 네트워크의 Edge 부분에 위치한 호스트의 프로토콜 스택만이 전송 계층을 가지며 , 네트워크의 핵심 부분에 있는 라우터는 패킷을 전달하며, 세 번째 계층(네트워크 계층으로)의 기능만 사용합니다.

프로세스 간 통신 프로세스

"논리적 통신"이란 전송 계층 간의 통신이 수평 방향으로 데이터를 전송하는 것처럼 보이지만 실제로는 두 데이터가 수평 방향으로 물리적으로 연결되어 있지 않은 것을 의미합니다. 전송되는 데이터는 점선을 따라 있습니다. 그림에서 여러 번 위아래로 선이 방향으로 전송됩니다.

프로세스 Ap1과 Ap4 간에는 네트워크 기반 통신이 수행되고, 프로세스 Ap2와 Ap3 간에는 네트워크 기반 통신이 수행됩니다.

다양한 애플리케이션 프로세스에 대응하기 위해 전송 계층에서 다양한 포트를 사용합니다.

그런 다음 애플리케이션 계층 메시지는 네트워크 계층과 그 하위 계층을 통해 전송됩니다.

수신기의 전송 계층은 수신한 애플리케이션 계층 메시지를 서로 다른 포트를 통해 애플리케이션 계층의 해당 애플리케이션 프로세스에 전달합니다.

여기서 포트는 가시적이고 유형적인 물리적 포트를 의미하는 것이 아니라 다양한 애플리케이션 프로세스를 구별하는 데 사용되는 식별자를 의미합니다.

요약하다

5.2 전송 계층 포트 번호, 다중화 및 역다중화 개념

포트 번호를 사용하는 이유는 무엇입니까?

송신 측 다중화 및 수신 측 다중화

다중 프로세스(여기서 포트는 프로세스를 나타냄)는 전송 계층 프로토콜(또는 전송 계층 인터페이스)을 사용하여 멀티플렉싱 이라는 데이터를 보냅니다 .

여러 프로세스(포트가 프로세스를 나타냄)가 전송 계층 프로토콜(또는 전송 계층 인터페이스)을 사용하여 을 수신하는 경우 이를 분할 이라고 합니다 .

전송 계층 전송 프로세스

브라우저에 도메인 이름을 입력하고 Enter를 눌러 찾아보세요.

그러면 사용자 PC의 DNS 클라이언트 프로세스가 DNS 쿼리 요청 메시지를 보냅니다.

DNS 쿼리 요청 메시지는 전송 계층의 UDP 프로토콜을 사용해야 합니다.

헤더의 소스 포트 필드 값은 49151~65535 사이에서 사용되지 않은 임시 포트 번호를 선택하여 DNS 클라이언트 프로세스를 나타냅니다.

헤더의 대상 포트 필드 값: 53은 DNS 서버 프로세스에서 사용하는 잘 알려진 포트 번호입니다.

그 후 UDP 사용자 데이터그램은 IP 데이터그램에 캡슐화되어 이더넷을 통해 DNS 서버로 전송됩니다.

IP 데이터그램을 수신한 후 DNS 서버는 UDP 사용자 데이터그램을 해독합니다.

UDP 헤더의 대상 포트 번호는 53입니다. 이는 UDP 사용자 데이터그램의 데이터 페이로드 부분, 즉 DNS 쿼리 요청 메시지가 이 서버의 DNS 서버 프로세스로 전달되어야 함을 나타냅니다.

DNS 서버 프로세스는 DNS 쿼리 요청 메시지의 내용을 분석한 다음 요구 사항에 따라 해당 IP 주소를 찾습니다.

그 후, DNS 응답 메시지가 사용자 PC로 전송되며, DNS 응답 메시지는 전송 계층의 UDP 프로토콜을 사용하여 UDP 사용자 데이터그램으로 캡슐화되어야 합니다.

헤더의 소스 포트 필드 값은 잘 알려진 포트 번호 53으로 설정되어 DNS 서버 프로세스에서 보낸 UDP 사용자 데이터그램임을 나타내고 대상 포트 값은 49152로 설정됩니다. 이전에 사용자 PC가 보낸 DNS 쿼리 요청 메시지 파일의 DNS 클라이언트 프로세스에서 사용하는 임시 포트 번호

UDP 사용자 데이터그램을 IP 데이터그램으로 캡슐화하여 이더넷을 통해 사용자 PC로 보냅니다.

사용자 PC는 데이터그램을 수신한 후 UDP 사용자 데이터그램의 차단을 해제합니다.

UDP 헤더의 대상 포트 번호는 49152입니다. 이는 UDP 사용자 데이터그램의 데이터 페이로드 부분, 즉 DNS 응답 메시지가 사용자 PC의 DNS 클라이언트 프로세스로 전달되어야 함을 나타냅니다.

DNS 클라이언트 프로세스는 DNS 응답 메시지의 내용을 구문 분석하여 이전에 요청한 웹 서버의 도메인 이름에 해당하는 IP 주소를 파악합니다.

이제 사용자 PC의 HTTP 클라이언트 프로세스는 HTTP 요청 메시지를 웹 서버에 보낼 수 있습니다(DNS 송수신 프로세스와 유사).

5.3 UDP와 TCP 비교

개념

UDP 와 TCP는 TCP/IP 아키텍처의 전송 계층 에서 중요한 두 가지 프로토콜 입니다.
전송 계층이 연결 지향 TCP 프로토콜을 채택하면 기본 네트워크가 신뢰할 수 없지만(최선의 서비스만 제공됨) 이 논리적 통신 채널은 전이중 신뢰할 수 있는 채널 과 동일합니다 .
전송 계층이 비연결형 UDP 프로토콜을 사용하는 경우 이 논리적 통신 채널은 신뢰할 수 없는 채널 입니다 .

신뢰할 수 있는 채널과 신뢰할 수 없는 채널

통신 중에 두 피어 전송 엔터티가 전송하는 데이터 단위를 TPDU( Transport Protocol Data Unit)라고 합니다.
TCP가 전송하는 데이터 단위 프로토콜은 TCP 세그먼트 입니다 .
UDP가 전송하는 데이터 단위 프로토콜은 UDP 메시지 또는 사용자 데이터그램 입니다 .

UDP 통신은 비연결형이며 소켓(Socket)이 필요하지 않습니다.

TCP는 연결 지향적이므로 TCP 간의 통신은 두 소켓(Socket) 사이에 연결을 설정해야 합니다.

사용자 데이터그램 프로토콜 UDP(사용자 데이터그램 프로토콜)

방송을 보낼 수 있음

멀티캐스트는 멀티캐스트 그룹으로 전송될 수 있습니다.

유니캐스트로 보낼 수도 있습니다

UDP는 유니캐스트, 멀티캐스트 및 브로드캐스트를 지원합니다.

즉 UDP는 일대일, 일대다, 일대다 통신을 지원한다.

운송 과정

UDP는 애플리케이션 프로세스에 의해 전달된 패킷을 병합하거나 분할하지 않지만 이러한 패킷의 경계를 유지합니다.

즉, UDP는 애플리케이션 패킷을 지향합니다.

UDP는 상위 계층에 연결이 없고 신뢰할 수 없는 전송 서비스를 제공합니다.

UDP 구조

전송 제어 프로토콜 TCP(전송 제어 프로토콜)

TCP 프로토콜을 사용하는 두 통신 당사자는 데이터 전송 전에 "3-메시지 핸드셰이크"를 사용하여 TCP 연결을 설정해야 합니다.

TCP 연결이 성공적으로 설정되면 통신 당사자 간에 안정적인 통신 채널이 있는 것으로 보이며, 통신 당사자는 TCP 연결을 기반으로 이 신뢰할 수 있는 채널을 사용하여 통신합니다.

당연히 TCP는 일대일 통신인 유니캐스트만 지원합니다.

운송 과정

보내는 사람

TCP는 애플리케이션 프로세스에 의해 전달된 데이터 블록을 일련의 비정형 바이트 스트림으로 간주하며 전송되는 이러한 바이트 스트림의 의미를 알지 못합니다.

번호를 매기고 자신의 전송 캐시에 저장하세요.

TCP는 전송 전략에 따라 일정량의 바이트를 추출하여 TCP 메시지를 구성하고 전송합니다.

수화기

한편으로는 데이터 페이로드 부분이 수신된 TCP 메시지 세그먼트에서 꺼내어 수신 버퍼에 저장되고, 다른 한편으로는 수신 버퍼의 일부 바이트가 애플리케이션 프로세스로 전달됩니다.

TCP는 수신자 애플리케이션 프로세스가 수신한 데이터 블록과 송신자가 보낸 데이터 블록이 상응하는 크기 관계를 갖는다는 것을 보장하지 않습니다. 수신된 바이트 스트림을 상위 응용 프로세스에 전달하기 위해 4개의 데이터 블록만 사용할 수 있지만, 수신자가 수신한 바이트 스트림은 송신자 응용 프로세스에서 보낸 바이트 스트림과 정확히 동일해야 합니다.

수신 애플리케이션 프로세스는 수신된 바이트 스트림을 식별하고 이를 의미 있는 애플리케이션 계층 데이터로 복원할 수 있어야 합니다.

TCP는 TCP가 안정적인 전송, 흐름 제어 및 혼잡 제어를 달성하기 위한 기반인 바이트 스트림을 지향합니다.

이 그림은 한 방향으로의 데이터 흐름만을 그린 것이며 실제 네트워크에서는 TCP 연결의 두 끝을 기반으로 TCP 세그먼트를 동시에 보내고 받을 수 있습니다.

TCP는 상위 계층에 연결 중심의 안정적인 전송 서비스를 제공합니다.

TCP 구조

요약하다

5.4 TCP 흐름 제어

개념

위 그림에서 호스트 A는 이제 호스트 B로부터 누적 확인을 받았기 때문에 송신 버퍼에 있는 시퀀스 번호 1부터 200까지의 모든 바이트 데이터를 삭제할 수 있습니다.

위 그림에서 호스트 A는 이제 호스트 B로부터 누적 확인을 받았기 때문에 송신 버퍼에 있는 일련 번호 201부터 500까지의 바이트 데이터를 모두 삭제할 수 있습니다.

위 그림에서 호스트 A는 호스트 B로부터 누적 확인을 받았기 때문에 전송 버퍼에 있는 일련 번호 501~600의 바이트 데이터를 모두 삭제할 수 있습니다.

위 그림에서 전송 과정에서 제로 윈도우 감지 메시지가 손실되더라도 교착 상태 상황은 여전히 깨질 수 있습니다.

제로 윈도우 감지 세그먼트에도 재전송 타이머가 있으므로 재전송 타이머 시간이 초과된 후 제로 윈도우 감지 세그먼트가 재전송됩니다.

요약하다

5.5 TCP 혼잡 제어

개념

네트워크 정체를 일으키는 요인

포인트 캐시의 용량이 너무 작습니다.
링크 용량이 부족합니다.
프로세서의 처리 속도가 너무 느립니다.
혼잡 자체가 혼잡을 더욱 악화시킬 수 있습니다.

혼잡 제어의 일반 원칙

혼잡 제어의 전제 조건: 네트워크가 기존 네트워크 부하를 감당할 수 있습니다.
혼잡 제어는 동적 문제 이기 때문에 설계하기 어렵다는 것이 실무를 통해 입증되었습니다 .
패킷 손실은 네트워크 정체의 원인이 아니라 증상 입니다.
많은 경우 혼잡 제어 자체가 네트워크 성능 저하 또는 교착 상태의 원인이 됩니다.

개방 루프 제어 및 폐쇄 루프 제어

네트워크 정체 모니터링

주요 지표는 다음과 같습니다.

버퍼 공간 부족으로 인해 삭제된 패킷 비율입니다.
평균 대기열 길이;
시간 초과 후 재전송된 패킷 수입니다.
평균 패킷 지연;
패킷 지연 등의 표준편차

이 지표의 상승은 혼잡이 증가했음을 나타냅니다.

혼잡제어 알고리즘

실제 송신 창 값 = Min(수신 창 값, 혼잡 창 값)

아래 예에서 수평 및 수직 좌표의 의미는 다음과 같습니다.

전송 라운드:

송신자가 수신자에게 데이터 세그먼트를 보낸 후 수신자는 해당 확인 세그먼트를 송신자에게 다시 보냅니다.
전송 라운드에 소요되는 시간은 실제로 왕복 시간이며 왕복 시간은 일정한 값이 아닙니다.
전송 라운드를 사용하는 목적은 혼잡 창에서 전송이 허용된 모든 메시지 세그먼트가 연속적으로 전송되고 전송된 마지막 메시지 세그먼트에 대한 확인을 받는다는 점을 강조하는 것입니다.

혼잡 기간:

네트워크 정체 정도와 사용되는 정체 제어 알고리즘에 따라 동적으로 변경됩니다.

느린 시작 및 혼잡 회피

느린 시작

목적: 네트워크의 부하 용량 또는 혼잡 수준을 결정하는 데 사용됩니다.
알고리즘의 아이디어: 혼잡 창 값을 작은 것에서 큰 것으로 점차적으로 늘립니다.
두 가지 변수:
- 혼잡창(cwnd) : 초기 혼잡창 값 : 2가지 설정 방법. 창 값이 점차 증가합니다.
  - 최대 세그먼트 1~2개(기존 표준)
  - 최대 세그먼트 2~4개(RFC 5681)
- 느린 시작 임계값(ssthresh) : 정체 창이 너무 커지거나 네트워크 정체가 발생하는 것을 방지합니다.

그림에서 swnd는 보내는 창입니다.

각 전송 라운드 후에 혼잡 창은 두 배로 늘어납니다.

창 크기는 2의 n-1승으로 기하 급수적으로 증가합니다.

혼잡 회피

아이디어: 혼잡을 피하기 위해 혼잡 창 cwnd를 천천히 증가 시키십시오.
각 전송 라운드 후에 혼잡 창 cwnd = cwnd + 1 .
혼잡 창 cwnd가 선형적으로 천천히 커지도록 만듭니다.
혼잡회피 단계에서는 " 부가적 증가" 의 특성을 갖는다 .

전송 프로세스 중에 일부 세그먼트가 손실되면 필연적으로 발신자가 시간 초과되어 손실된 세그먼트를 다시 전송하게 됩니다.

이때 슬로우 스타트로 돌아갑니다.

두 알고리즘의 완전한 개략도

빠른 재전송 및 빠른 복구

빠른 재전송(빠른 재전송)

빠른 복구

개선된 전체 알고리즘의 개략도

5.6 TCP 타임아웃 재전송 시간 선택

타임아웃 재전송 시간 RTO의 값이 RTT0의 값보다 훨씬 작게 설정되면 메시지 세그먼트의 불필요한 재전송이 발생하고 네트워크 부하가 증가하게 됩니다.

타임아웃 재전송 시간(RTO)의 값이 RTT0의 값보다 훨씬 크게 설정되면 재전송 시간이 너무 오래 지연되어 네트워크의 유휴 시간이 늘어나고 전송 효율성이 저하됩니다.

RFC6298에서는 다음 공식을 사용하여 제한 시간 재전송 시간 RTO를 계산할 것을 권장합니다.

왕복 시간 RTT 측정이 더 복잡합니다.

TCP 시간 초과 재전송 계산

요약하다

5.7 TCP 신뢰성 전송 구현

5.8 TCP 전송 연결 관리

개념

TCP 연결 설정

TCP 연결을 설정하는 프로세스를 핸드셰이크 라고 합니다 .
핸드셰이크에는 클라이언트와 서버 간에 세 개의 TCP 세그먼트 교환이 필요합니다. 이를 3-메시지 핸드셰이크 라고 합니다 .
3-메시지 핸드셰이크는 유효하지 않은 연결 요청 세그먼트가 갑자기 다시 전송되어 오류가 발생하는 것을 방지하기 위해 주로 사용됩니다 .

TCP 연결 설정은 다음 세 가지 문제를 해결해야 합니다.

TCP는 "3-패킷 핸드셰이크"를 사용하여 연결을 설정합니다.

TCP 연결은 클라이언트-서버 방식을 사용하여 설정됩니다 .
연결 설정을 적극적으로 시작하는 애플리케이션 프로세스를 TCP 클라이언트 라고 합니다 .
연결이 설정될 때까지 수동적으로 기다리는 애플리케이션 프로세스를 TCP 서버 라고 합니다 .

"핸드셰이크"에는 TCP 클라이언트와 서버 간에 세 개의 TCP 세그먼트 교환이 필요합니다.

프로세스

처음에는 양쪽 끝의 TCP 프로세스가 닫힙니다.

처음에 TCP 서버 프로세스는 먼저 TCP 연결에 몇 가지 중요한 정보를 저장하기 위해 전송 제어 블록을 생성합니다. 예를 들어 TCP 연결 테이블, 송신 및 수신 버퍼에 대한 포인터, 재전송 큐에 대한 포인터, 현재 송신 및 수신 시퀀스 번호 등이 있습니다.

그런 다음 TCP 클라이언트 프로세스의 연결 요청을 수락할 준비를 합니다.

이 시점에서 TCP 서버 프로세스는 Listening 상태로 진입하여 TCP 클라이언트 프로세스의 연결 요청을 기다린다.

TCP 서버 프로세스는 TCP 클라이언트 프로세스의 연결 요청을 수동적으로 기다리므로 수동 개방 연결이 됩니다.

TCP 클라이언트 프로세스도 먼저 전송 제어 블록을 생성합니다.

TCP 연결 설정은 TCP 클라이언트에 의해 시작되므로 이를 능동적으로 연결 열기 라고 합니다.

그런 다음 TCP 연결을 설정하려는 경우 TCP 연결 요청 세그먼트를 TCP 서버 프로세스에 보내고 동기화된 전송 상태로 들어갑니다.

TCP 연결 요청 세그먼트 헤더에서

동기화 비트 SYN은 1로 설정되어 이것이 TCP 연결 요청 세그먼트임을 나타냅니다.

시퀀스 번호 필드 seq는 TCP 클라이언트 프로세스에서 선택한 초기 시퀀스 번호인 초기 값 x로 설정됩니다.

참고: TCP는 SYN이 1로 설정된 메시지 세그먼트는 데이터를 전달할 수 없지만 시퀀스 번호를 사용해야 한다고 규정합니다.

TCP 서버 프로세스는 TCP 연결 요청 세그먼트를 수신한 후 연결 설정에 동의하면 다음을 보냅니다.

TCP 연결 요청은 메시지 세그먼트를 확인하고 동기화 수신 상태로 들어갑니다.

TCP 연결 요청 확인 메시지 세그먼트의 헤더에서

동기화 비트 SYN과 확인 비트 ACK는 모두 1로 설정되어 이것이 TCP 연결 요청 확인 세그먼트임을 나타냅니다.

시퀀스 번호 필드 seq는 TCP 서버 프로세스에서 선택한 초기 시퀀스 번호인 초기 값 y로 설정됩니다.

확인 번호 필드 ack의 값은 x+1로 설정됩니다. 이는 TCP 클라이언트 프로세스에서 선택한 초기 시퀀스 번호(seq)에 대한 확인입니다.

참고: 이 세그먼트는 SYN이 1로 설정된 세그먼트이기 때문에 데이터를 전달할 수 없지만 시퀀스 번호도 소비합니다.

TCP 클라이언트 프로세스는 TCP 연결 요청 확인 메시지 세그먼트를 수신한 후 일반 TCP 확인 메시지 세그먼트도 TCP 서버 프로세스에 보내고 연결 연결 상태로 들어갑니다.

일반 TCP 승인 메시지 세그먼트의 헤더

승인 비트 ACK는 1로 설정되어 이것이 일반적인 TCP 승인 세그먼트임을 나타냅니다.

시퀀스 번호 필드 seq는 x+1로 설정되는데 이는 TCP 클라이언트 프로세스가 보낸 첫 번째 TCP 세그먼트의 시퀀스 번호가 x이고 TCP 클라이언트 프로세스가 보낸 두 번째 세그먼트의 시퀀스 번호가 x+1이기 때문입니다. .

승인 번호 필드 ack는 y+1로 설정됩니다. 이는 TCP 서버 프로세스에서 선택한 초기 시퀀스 번호를 확인하는 것입니다.

참고: TCP는 일반 TCP 확인 메시지 세그먼트가 데이터를 전달할 수 있다고 규정하지만, 데이터를 전달하지 않는 경우 시퀀스 번호는 소비되지 않습니다.

확인 메시지 세그먼트를 수신한 후 TCP 서버 프로세스도 연결 설정 상태로 들어갑니다.

이제 두 TCP 당사자 모두 연결 확립 상태에 진입했으며, 확립된 TCP 연결을 기반으로 안정적인 데이터 전송을 수행할 수 있습니다.

TCP 클라이언트 프로세스가 최종적으로 일반 TCP 확인 세그먼트를 보내는 이유는 무엇입니까? 연결을 설정하기 위해 "2-패킷 핸드셰이크"를 사용할 수 있습니까?

아래 그림의 예는 "두 메시지 간의 핸드셰이크"입니다.

잘못된 연결 요청 메시지 세그먼트가 갑자기 서버에 전송되어 오류가 발생하는 것을 방지하기 위해 클라이언트 A가 보낸 첫 번째 연결 요청 메시지는 > 손실되지 않았지만 알 수 없는 이유로 메시지가 다음과 같이 됩니다. 특정 네트워크 노드에서 정체되어 연결이 해제된 후 일정 시간이 될 때까지 상대방(서버) B에 도달하는 데 지연이 발생합니다. 원래는 이미 만료된 세그먼트였지만 B는 이를 수신했습니다. 잘못된 메시지를 받은 후, 이는 A가 다시 보낸 새로운 연결 요청으로 착각할 것이므로 B는 A에게 연결 설정에 동의한다는 또 다른 확인 메시지를 보냅니다. "3방향 핸드셰이크"를 사용하지 않는 경우 B는 단말에서 확인 메시지를 보내면 새로운 연결이 이루어진 것으로 생각하지만 A측에서는 연결 설정 요청을 보내지 않았으므로 B측으로 데이터를 보내지 않습니다. 데이터를 계속 기다리게 된다. B 결국 많은 자원을 낭비하게 되므로 중복되지
않게 된다 . 이는 만료된 연결 요청 세그먼트가 갑자기 TCP 서버로 전송되어 오류가 발생하는 것을 방지하기 위함이다.

요약하다

TCP 연결 해제

TCP 연결 해제 프로세스는 더 복잡합니다.
데이터 전송이 완료되면 통신 당사자 모두 연결을 해제할 수 있습니다.
TCP 연결 해제 프로세스는 4패킷 핸드셰이크 입니다 .

TCP는 "4개의 메시지 웨이브"를 통해 연결을 해제합니다.

TCP 연결은 클라이언트-서버 방식을 사용하여 설정됩니다 .
연결 설정을 적극적으로 시작하는 애플리케이션 프로세스를 TCP 클라이언트 라고 합니다 .
연결이 설정될 때까지 수동적으로 기다리는 애플리케이션 프로세스를 TCP 서버 라고 합니다 .
어느 쪽이든 데이터 전송이 완료된 후 연결 해제 알림을 보낼 수 있습니다.

프로세스

이제 TCP 클라이언트 프로세스와 TCP 서버 프로세스 모두 연결이 설정된 상태입니다.

TCP 클라이언트 프로세스의 애플리케이션 프로세스는 TCP 연결을 적극적으로 닫으라고 알립니다.

TCP 클라이언트 프로세스는 TCP 연결 해제 메시지 세그먼트를 보내고 종료 대기 1 상태로 들어갑니다.

TCP 연결 해제 세그먼트 헤더

종료 비트 FIN과 확인된 ACK 값은 모두 1로 설정되어 TCP 연결 해제 세그먼트임을 나타내며 이전에 수신한 세그먼트도 확인합니다.

시퀀스 번호 seq 필드의 값은 u로 설정됩니다. 이는 TCP 클라이언트 프로세스가 이전에 전송한 데이터의 마지막 바이트의 시퀀스 번호에 1을 더한 것과 같습니다.

확인 번호 ack 필드의 값은 v로 설정되며, 이는 TCP 클라이언트 프로세스가 이전에 수신한 데이터의 마지막 바이트의 시퀀스 번호에 1을 더한 것과 같습니다.

참고: TCP는 종료 비트 FIN이 1인 메시지 세그먼트가 데이터를 전달하지 않더라도 시퀀스 번호를 소비하도록 규정합니다.

TCP 서버 프로세스는 TCP 연결 해제 세그먼트를 수신한 후 일반 TCP 확인 세그먼트를 보내고 종료 대기 상태로 들어갑니다.

일반 TCP 승인 메시지 세그먼트의 헤더

승인 비트 ACK의 값은 1로 설정되어 이것이 일반 TCP 승인 세그먼트임을 나타냅니다.

시퀀스 번호 seq 필드의 값은 v로 설정됩니다. 이는 TCP 서버 프로세스가 이전에 전송한 데이터의 마지막 바이트의 시퀀스 번호에 1을 더한 것과 같습니다. 이는 이전에 수신한 TCP 연결 해제 메시지의 확인 번호와도 일치합니다. 분절.

확인번호 ack 필드의 값은 TCP 연결 해제 세그먼트의 확인인 u+1로 설정된다.

TCP 서버 프로세스는 TCP 클라이언트 프로세스가 자신의 TCP 연결을 끊어야 함을 상위 수준 애플리케이션 프로세스에 알려야 합니다.

이때 TCP 클라이언트 프로세스에서 TCP 서버 프로세스로의 연결이 해제된다.

이때 TCP 연결은 반폐쇄(semi-closed) 상태입니다. 즉, TCP 클라이언트 프로세스에는 전송할 데이터가 없습니다.

그러나 TCP 서버 프로세스에 아직 보낼 데이터가 있으면 TCP 클라이언트 프로세스는 이를 수신해야 합니다. 이는 TCP 서버 프로세스에서 TCP 클라이언트 프로세스로의 연결이 닫히지 않았음을 의미합니다.

TCP 확인 메시지 세그먼트를 수신한 후 TCP 클라이언트 프로세스는 종료 대기 2 상태에 진입하고 TCP 서버 프로세스가 보낸 TCP 연결 해제 메시지 세그먼트를 기다립니다.

TCP 서버 프로세스를 사용하는 응용 프로세스가 전송할 데이터가 없으면 응용 프로세스는 TCP 서버 프로세스에 연결을 해제하도록 알립니다.

TCP 연결 해제는 TCP 클라이언트 프로세스에 의해 능동적으로 시작되므로 TCP 서버 프로세스에 의한 TCP 연결 해제를 수동적 연결 종료라고 합니다.

TCP 서버 프로세스는 TCP 연결 해제 세그먼트를 보내고 최종 확인 상태로 들어갑니다.

이 메시지 세그먼트의 헤더에서

종료 비트 FIN과 승인 비트 ACK의 값은 모두 1로 설정되어 이는 TCP 연결 해제 세그먼트임을 나타내며 이전에 수신한 세그먼트도 확인합니다.

시퀀스 번호 seq 필드의 값은 w입니다. 이는 반 폐쇄 상태에서 TCP 서버 프로세스가 다른 메시지를 보낼 수 있기 때문입니다.

확인 번호 ack 필드의 값은 u+1로, 이는 이전에 수신한 TCP 연결 해제 세그먼트에 대한 반복 확인을 의미한다.

TCP 연결 해제 메시지 세그먼트를 수신한 후 TCP 클라이언트 프로세스는 해당 메시지 세그먼트에 대한 일반 TCP 확인 메시지 세그먼트를 전송한 후 시간 대기 상태로 들어가야 합니다.

이 메시지 세그먼트의 헤더에서

ACK 값은 1로 설정되어 정상적인 TCP 승인 세그먼트임을 나타냅니다.

시퀀스 번호 seq 필드의 값은 u+1로 설정되는데 이는 TCP 클라이언트 프로세스가 이전에 보낸 TCP 연결 해제 메시지 세그먼트가 데이터를 전달하지 않지만 시퀀스 번호를 소비하기 때문입니다.

확인번호 ack 필드의 값은 수신된 TCP 연결 해제 세그먼트에 대한 확인인 w+1로 설정된다.

TCP 서버 프로세스는 메시지 세그먼트를 수신한 후 닫힌 상태에 들어가고, TCP 클라이언트 프로세스는 2MSL을 거쳐야 닫힌 상태에 들어갈 수 있습니다.

TCP 클라이언트 프로세스가 마지막 확인 메시지를 보낸 후 왜 직접 종료 상태로 들어가지 않습니까? 그런데 시간 대기 상태로 들어가려면?

이 상태의 시간 대기 상태와 2MSL 기간으로 인해 TCP 서버 프로세스가 마지막 TCP 확인 메시지 세그먼트를 수신하고 닫힌 상태로 들어갈 수 있음을 보장할 수 있습니다.

또한 TCP 클라이언트 프로세스가 마지막 TCP 확인 메시지 세그먼트를 보낸 후 2MSL 이후 이 연결 기간 동안 생성된 모든 메시지 세그먼트는 네트워크에서 사라질 수 있으므로 다음 메시지 세그먼트는 새 TCP 연결에서 메시지 이전 연결의 세그먼트는 나타나지 않습니다.

TCP keepalive 타이머의 역할

TCP 두 당사자가 연결을 설정했는데 나중에 TCP 클라이언트 프로세스가 있는 호스트에 갑자기 장애가 발생했습니다.

TCP 서버 프로세스는 앞으로 더 이상 TCP 클라이언트 프로세스로부터 데이터를 수신하지 않습니다.

그러므로 TCP 서버 프로세스가 헛되이 기다리는 것을 방지하기 위한 대책이 필요하다.

5.9 TCP 세그먼트의 헤더 형식

각 분야의 역할

소스 포트와 대상 포트

일련 번호, 확인 번호 및 확인 플래그

데이터 오프셋, 보존, 윈도잉 및 패리티

동기화 플래그, 종료 플래그, 재설정 플래그, 푸시 플래그, 비상 플래그 및 비상 포인터

옵션 및 패딩