Java의 tcp, udp 및 ip 프로토콜에 대한 그래픽 소개-java지도 시간-php.cn

이 글은 주로 tcp, udp, ip 프로토콜 분석 관련 정보를 자세하게 소개하고 있습니다. 관심있는 친구들이 참고하면 좋을 것 같습니다.

인터넷 초창기에는 호스트 간 상호 연결이 사용되었습니다. NCP 프로토콜. 이 프로토콜 자체에는 서로 다른 호스트를 상호 연결할 수 없고, 서로 다른 운영 체제를 상호 연결할 수 없으며 오류 수정 기능이 없는 등 많은 결함이 있습니다. 이러한 단점을 개선하기 위해 다니엘은 TCP/IP 프로토콜을 고안했습니다. 이제 거의 모든 운영 체제는 TCP/IP 프로토콜 스택을 구현합니다.

TCP/IP 프로토콜 스택은 주로 애플리케이션 계층, 전송 계층, 네트워크 계층 및 데이터 링크 계층의 네 가지 계층으로 나뉩니다. 각 계층에는 아래와 같이 해당 프로토콜이 있습니다.

소위 프로토콜 양 당사자가 수행하는 데이터 전송 형식입니다. 네트워크 전반에 걸쳐 많은 프로토콜이 사용되며 다행히 각 프로토콜에는 RFC 문서가 있습니다. 여기서는 IP, TCP, UDP 프로토콜 헤더만 분석합니다.

먼저 네트워크에서 이더넷 데이터 패킷의 형식을 살펴보겠습니다.

Linux 운영 체제에서는 데이터를 보내려고 할 때 상위에 있는 데이터만 준비하면 됩니다. 레이어를 작성한 다음 이를 커널 프로토콜 스택에 제출하면 커널 프로토콜 스택이 자동으로 해당 프로토콜 헤더를 추가합니다. 각 레이어에 추가되는 프로토콜 헤더의 구체적인 내용을 살펴보겠습니다.

1. TCP 프로토콜

TCP 프로토콜은 높은 신뢰성(데이터 손실 없음, 데이터 장애 없음, 데이터 오류 없음, 중복 데이터 도착 없음)을 보장하는 연결 지향 전송 계층 프로토콜입니다.

1.TCP 헤더 분석

먼저 TCP 헤더의 형식과 각 필드의 의미를 분석합니다.

(1) 포트 번호 [16bit]

우리는 네트워크 구현을 알고 있습니다. 서로 다른 호스트 간의 프로세스 간 통신입니다. 운영 체제에는 많은 프로세스가 있습니다. 데이터가 도착하면 처리를 위해 어떤 프로세스를 제출해야 합니까? TCP 헤더에는 소스 포트 번호(Source Port)와 목적지 포트 번호(Destination Port)가 있습니다. 소스 포트 번호는 송신 호스트의 프로세스를 식별하고, 대상 포트 번호는 수신 호스트의 프로세스를 식별합니다.

(2) 시퀀스 번호 [32비트]

시퀀스 번호는 Sequence Number와 Acknowledgement Number로 구분됩니다.

전송 시퀀스 번호: TCP 소스에서 TCP 대상으로 전송된 데이터 바이트 스트림을 식별하는 데 사용됩니다. 이는 이 메시지 세그먼트의 첫 번째 데이터 바이트의 시퀀스 번호를 나타냅니다. 바이트 스트림을 두 애플리케이션 간의 단방향 흐름으로 생각하면 TCP는 시퀀스 번호를 사용하여 각 바이트를 계산합니다. 일련번호는 32비트 부호 없는 숫자입니다. 일련번호는 2 32-1에 도달한 후 0부터 시작됩니다. 새 연결이 설정되면 SYN 플래그가 1로 변경되고 시퀀스 번호 필드에는 이 호스트가 연결을 위해 선택한 초기 시퀀스 번호 ISN(초기 시퀀스 번호)이 포함됩니다.

확인 시퀀스 번호: 확인을 보내는 쪽에서 수신할 것으로 예상하는 다음 시퀀스 번호가 포함되어 있습니다. 따라서 확인 시퀀스 번호는 마지막으로 성공적으로 수신된 데이터 바이트 시퀀스 번호에 1을 더한 것이어야 합니다. 확인 시퀀스 번호 필드는 ACK 플래그가 1인 경우에만 유효합니다. TCP는 애플리케이션 계층에 전이중 서비스를 제공합니다. 이는 데이터가 양방향으로 독립적으로 전송될 수 있음을 의미합니다. 따라서 연결의 각 끝은 각 방향으로 전송되는 데이터의 시퀀스 번호를 유지해야 합니다.

(3) 오프셋 [4bit]

여기서 오프셋은 실제로 TCP 헤더의 길이를 의미하며 이를 통해 TCP 헤더의 32비트 단어 수를 알 수 있습니다. TCP 패킷의 사용자 데이터는 어디에서 시작됩니까? 이 필드는 4비트를 차지한다. 4비트의 값이 0101이면 TCP 헤더 길이가 5*4=20바이트라는 뜻이다. 따라서 최대 TCP 헤더 길이는 15 * 4 = 60바이트입니다. 단, 선택적 필드는 없으며 일반 길이는 20바이트입니다.

(4)Reserved [6bit]

현재 사용되지 않으며 값은 0

(5) Flag [6bit]

TCP 헤더에는 6개의 플래그 비트가 있습니다. 동시에 여러 개를 1로 설정할 수 있습니다. > through through ’ through ’ s ’ through ’ through through through through through through ’ through to ’ through to ‐‐‐ ‐ ‐ to to to

예: TCP 클라이언트 Wirshark는 수신 포트가 없는 서버에 대한 연결을 시작합니다. 192.168.63.132는 해당 포트를 수신하는 서버 측에 없습니다. 이때

host: 192.168.63.132는 연결 끊김으로 설정된 RST를 사용하여 TCP 패킷을 보냅니다.

序Syn 동기 일련 번호는 바이트 수만큼 연결을 시작하는 데 사용됩니다. .

(7) 체크섬 [16비트]

체크섬은 전체 TCP 메시지 세그먼트(TCP 헤더 및 TCP 데이터)를 포괄합니다. 이는 발신자가 계산 및 저장하고 수신자가 확인해야 하는 필수 필드입니다.

(8) 비상 포인터 [16비트]

비상 포인터는 URG 플래그가 1로 설정된 경우에만 유효합니다. 긴급 포인터는 긴급 데이터의 마지막 바이트의 시퀀스 번호를 나타내기 위해 시퀀스 번호 필드의 값에 추가되는 양의 오프셋입니다. TCP의 긴급 모드는 발신자가 긴급한 데이터를 상대방에게 보내는 방법입니다.

(9)TCP 옵션

은 선택 사항입니다. 나중에 패킷을 캡처할 때 살펴보겠습니다.

2. 주요 세부 정보

(1) 연결 설정을 위한 3방향 핸드셰이크

a. 요청 측(종종 클라이언트라고 함)은 클라이언트가 연결하려는 서버의 포트와 초기 시퀀스 번호(ISN, 이 예에서는 1415531521)를 나타내는 SYN 세그먼트를 보냅니다. 이 SYN 세그먼트는 메시지 세그먼트 1입니다.

b. 서버는 서버의 초기 시퀀스 번호가 포함된 SYN 세그먼트(세그먼트 2)를 응답으로 다시 보냅니다. 동시에 고객의 SYN 메시지 세그먼트를 확인하기 위해 확인 시퀀스 번호가 고객의 ISN에 1을 더한 값으로 설정됩니다. SYN은 시퀀스 번호를 차지합니다c. 클라이언트는 서버의 SYN 세그먼트(세그먼트 3)를 확인하기 위해 서버의 ISN에 1을 더한 확인 시퀀스 번호를 설정해야 합니다.
이 세 세그먼트가 연결 설정을 완료합니다. 이 프로세스를 3방향 핸드셰이크라고도 합니다.

다음과 같이 wirshark를 사용하여 패킷을 캡처합니다.

3방향 핸드셰이크가 두 프로세스 사이의 패킷 시퀀스 번호를 결정하는 것을 볼 수 있습니다. 두 당사자 및 허용되는 최대 데이터 수 크기(창) 및 MSS(최대 세그먼트 크기).

MSS = MTU - IP 헤더 - TCP 헤더. MTU는 IP 헤더를 분석할 때 최대 전송 단위를 나타냅니다. 일반적으로 1500바이트입니다. IP 헤더와 TCP 헤더는 모두 20바이트이며 선택적 옵션이 있습니다. 이 경우 MSS=1500 - 20 -20 = 1460입니다.

MSS는 TCP 패킷이 전달하는 데이터의 크기를 제한합니다. 이는 애플리케이션 계층이 TCP 프로토콜을 통해 전송하기 위해 데이터를 전송 계층에 제출할 때 애플리케이션 계층 데이터 > MSS인 경우 여러 세그먼트로 분할되어야 함을 의미합니다. 하나씩 보내주세요.

예를 들어 애플리케이션 계층은 한 번에 4096바이트의 데이터를 전송 계층에 제출합니다. 이때 wirshark를 통한 패킷 캡처 효과는 다음과 같습니다.

처음 세 번은 다음과 같은 과정입니다. three-way handshake이고 다음 3번은 데이터를 전송하는 과정입니다. 데이터 크기가 4096바이트이므로 3번의 패스(1448 + 1448 + 1200)가 필요합니다. 조심스러운 사람들은 왜 매번 전송되는 최대 데이터 크기가 1460바이트가 아닌지 묻습니다. 여기서 TCP는 선택적 옵션을 전달하므로 TCP 헤더 길이 = 20 + 12(선택적 옵션 크기) = 32바이트입니다. 이 방법으로 전송할 수 있는 최대 데이터는 1500 - 20 - 32 = 1448바이트입니다.

(2) 연결을 끊기 위해 4번 웨이브

a. 현재 네트워크 통신은 소켓을 기반으로 합니다. 클라이언트가 자체 소켓을 닫으면 커널 프로토콜 스택이 자동으로 FIN 설정을 서버에 보냅니다. 단절. 먼저 연결 해제 요청을 시작한 당사자를 활성 연결 해제 당사자로 호출합니다.
b. 서버가 클라이언트로부터 FIN 연결 해제 요청을 받은 후, 커널 프로토콜 스택은 즉시 클라이언트의 요청이 수신되었음을 나타내는 ACK 패킷을 보냅니다.

c. 시간이 지나면 자체 소켓을 닫습니다. 이때 커널 프로토콜 스택은 FIN 세트 패킷을 클라이언트에 보내 연결 해제를 요청합니다. 클라이언트는 서버로부터 FIN 연결 해제 요청을 받은 후 응답으로 요청을 수신했음을 나타내는 ACK를 보냅니다.

은 다음과 같이 패킷을 캡처하기 위해 wirshar를 사용하여 분석됩니다.

(3) TCP 신뢰성 보장

TCP는 안정적인 데이터 전송 서비스를 제공하기 위한 기반으로 "재전송을 통한 긍정 승인"이라는 기술을 사용합니다. 이 기술에서는 수신기가 데이터를 수신한 후 확인 정보 ACK를 소스 스테이션으로 다시 보내야 합니다. 발신자는 전송된 각 패킷의 기록을 유지하고 다음 패킷을 전송하기 전에 확인을 기다립니다. 또한 송신자는 패킷을 보내는 동안 타이머를 시작하고 타이머가 만료되었지만 승인 정보가 도착하지 않은 경우 방금 보낸 패킷을 다시 보냅니다. 그림 3-5는 재전송 기능이 있는 긍정 응답 프로토콜의 데이터 전송 상황을 보여주며, 그림 3-6은 패킷 손실로 인한 타임아웃 및 재전송을 보여줍니다. 네트워크 지연으로 인한 지연 승인 및 중복 승인을 방지하기 위해 프로토콜은 수신자가 패킷을 승인과 올바르게 연결할 수 있도록 승인 정보에 패킷 시퀀스 번호가 포함되도록 규정합니다.

그림 3-5에서 볼 수 있듯이 네트워크는 동시에 양방향 통신을 수행할 수 있지만 단순 긍정 확인 프로토콜은 다음 패킷 전송을 연기해야 하기 때문에 귀중한 데이터를 많이 낭비합니다. 이전 패킷 네트워크 대역폭의 확인 정보를 받기 전에. 이를 위해 TCP는 슬라이딩 윈도우 메커니즘을 사용하여 엔드투엔드 흐름 제어를 해결하는 동시에 네트워크 처리량을 향상시킵니다.

(4) 슬라이딩 윈도우 기술

슬라이딩 윈도우 기술은 발신자가 하나의 그룹을 기다리기 전에 여러 개의 승인을 보낼 수 있도록 하는 재전송 기능이 있는 단순 긍정적 승인 메커니즘의 더 복잡한 변형입니다. 그림 3-7에 표시된 것처럼 송신자는 패킷 시퀀스를 보내려고 합니다. 슬라이딩 윈도우 프로토콜은 패킷 시퀀스에 고정 길이 윈도우를 배치한 다음 송신자가 패킷의 시퀀스를 수신하면 윈도우에 있는 모든 패킷을 보냅니다. 확인 정보가 수신되면 뒤로 슬라이드하여 다음 패킷을 보낼 수 있으며 확인이 계속 도착하면 창이 계속 뒤로 슬라이드됩니다.

2. UDP 프로토콜

UDP 프로토콜 역시 전송 계층 프로토콜이므로 신뢰성을 보장하지 않습니다. 프로토콜 헤더는 다음과 같이 비교적 간단합니다.

여기서 포트 번호는 설명하지 않으며 TCP 포트 번호와 동일한 의미를 갖습니다.

Length는 2바이트를 차지하며 UDP 헤더의 길이를 식별합니다. 체크섬: UDP 헤더 및 데이터 부분을 포함한 체크섬입니다.

3. IP 프로토콜

IP는 TCP/IP 프로토콜 계열의 핵심 프로토콜입니다. 모든 TCP, UDP, ICMP 및 IGMP 데이터는 IP 데이터그램 형식으로 전송됩니다. 그 특징은 다음과 같습니다.
신뢰할 수 없음(unreliable)은 IP 데이터그램이 대상에 성공적으로 도달할 수 있다는 것을 보장할 수 없음을 의미합니다. IP는 최고의 전송 서비스만을 제공합니다. 라우터에 일시적으로 버퍼가 부족해지는 등 오류가 발생하는 경우 IP에는 간단한 오류 처리 알고리즘이 있습니다. 즉, 데이터그램을 삭제한 다음 ICMP 메시지를 소스에 보냅니다. 필요한 신뢰성은 상위 계층(예: TCP)에서 제공되어야 합니다.

무연결(연결) 이 용어는 IP가 후속 데이터그램에 대한 상태 정보를 유지하지 않음을 의미합니다. 각 데이터그램은 서로 독립적으로 처리됩니다. 이는 또한 IP 데이터그램이 전송된 순서와 상관없이 수신될 수 있음을 의미합니다. 소스가 두 개의 연속적인 데이터그램(첫 번째 A, 다음 B)을 동일한 싱크로 보내는 경우 각 데이터그램은 독립적으로 라우팅되어 다른 경로를 사용할 수 있으므로 A가 도착하기 전에 B가 도착할 수 있습니다.

1.IP 헤더 형식

(1) 버전은 4자리를 차지하며 IP 프로토콜의 버전을 나타냅니다. 두 통신 당사자가 사용하는 IP 프로토콜 버전은 일관되어야 합니다. 현재 널리 사용되는 IP 프로토콜 버전 번호는 4(IPv4)입니다. IPv6에 관해서는 아직 초안 단계입니다.

(2) 헤더 길이는 4자리를 차지하며, 표현 가능한 최대 소수점 값은 15이다. 이 필드가 나타내는 숫자의 단위는 32비트 워드 길이(32비트 워드 길이는 4바이트)이므로, IP 헤더 길이가 1111(즉, 10진수로 15)인 경우 헤더는 길이가 60바이트에 도달합니다. IP 패킷 헤더의 길이가 4바이트의 정수배가 아닌 경우 마지막 패딩 필드로 채워야 합니다. 따라서 데이터 부분은 항상 4바이트의 정수배로 시작하므로 IP 프로토콜을 구현할 때 더 편리합니다. 헤더 길이를 60바이트로 제한하면 어떤 경우에는 충분하지 않을 수 있다는 단점이 있습니다. 그러나 이는 사용자가 오버헤드를 최소화할 것이라는 희망으로 수행됩니다. 가장 일반적으로 사용되는 헤더 길이는 20바이트(즉, 헤더 길이는 0101)이며, 이때는 옵션이 사용되지 않는다.

(3) 차별화된 서비스: 더 나은 서비스를 얻기 위해 8비트가 사용됩니다. 이 필드는 기존 표준에서는 서비스 유형(Service Type)이라고 불렸지만 실제로는 사용된 적이 없습니다. 1998년에 IETF는 이 필드의 이름을 DS(Differentiated Services)로 변경했습니다. 이 필드는 차별화된 서비스를 사용할 때만 적용됩니다.

(4) 전체 길이 전체 길이는 헤더와 데이터의 길이(바이트)를 의미합니다. 전체 길이 필드는 16비트이므로 데이터그램의 최대 길이는 216-1 = 65535바이트입니다.

IP 계층 아래의 각 데이터 링크 계층에는 자체 프레임 형식이 있으며, 여기에는 최대 전송 단위(MTU)라고 하는 프레임 형식의 데이터 필드의 최대 길이가 포함됩니다. 데이터그램이 링크 계층 프레임으로 캡슐화되면 데이터그램의 전체 길이(즉, 헤더와 데이터 부분을 더한 길이)가 기본 데이터 링크 계층의 MTU 값을 초과해서는 안 됩니다.

(5)신분증(ID)은 16자리를 차지합니다. IP 소프트웨어는 데이터그램이 생성될 때마다 카운터를 메모리에 유지하며 이 값은 식별 필드에 할당됩니다. 그러나 이 "식별"은 시퀀스 번호가 아닙니다. IP는 연결이 없는 서비스이고 데이터그램을 순서대로 수신하는 데 문제가 없기 때문입니다. 데이터그램의 길이가 네트워크의 MTU를 초과하여 데이터그램을 조각화해야 하는 경우 이 식별 필드의 값이 모든 데이터그램의 식별 필드에 복사됩니다. 동일한 식별 필드 값을 사용하면 조각난 각 데이터그램 조각을 원본 데이터그램으로 올바르게 재조립할 수 있습니다.

(6) 플래그(flag)는 3자리 숫자를 차지하지만, 현재는 2자리만 의미가 있습니다.

●플래그 필드의 가장 낮은 비트는 MF(More Fragment)로 기록됩니다. MF=1은 나중에 "조각화된" 데이터그램이 있음을 의미합니다. MF=0은 이것이 여러 데이터그램 조각 중 마지막임을 의미합니다. 플래그 필드의 중간에 있는 비트는 "조각화할 수 없음"을 의미하는 DF(Don't Fragment)로 기록됩니다. 조각화는 DF=0인 경우에만 허용됩니다.

(7) 조각 오프셋은 13비트를 차지합니다. 슬라이스 오프셋은 더 긴 패킷이 조각화된 후 원래 패킷에서 특정 슬라이스의 상대적 위치를 나타냅니다. 즉, 사용자 데이터 필드의 시작점을 기준으로 조각이 시작되는 위치입니다. 슬라이스 오프셋은 8바이트 오프셋 단위입니다. 이는 각 조각의 길이가 8바이트(64비트)의 정수 배수여야 함을 의미합니다.

(8) Time to Live는 8비트를 차지합니다. 일반적으로 사용되는 Time To Live 필드의 영어 약어는 TTL(Time To Live)이며, 이는 네트워크에서 데이터그램의 수명을 나타냅니다. 이 필드는 데이터그램의 원본에 의해 설정됩니다. 그 목적은 전달할 수 없는 데이터그램이 인터넷에서 무기한 순환되어 네트워크 리소스를 헛되이 소모하는 것을 방지하는 것입니다. 원래 디자인은 초를 TTL 단위로 사용하는 것이었습니다. 라우터를 통과할 때마다 데이터그램이 라우터에서 소비하는 시간에서 TTL을 뺍니다. 데이터그램이 라우터에서 1초 미만이면 TTL 값이 1씩 감소합니다. TTL 값이 0이면 데이터그램이 삭제됩니다.

(9) 프로토콜은 8비트를 차지합니다. 프로토콜 필드는 이 데이터그램에 전달되는 데이터에 어떤 프로토콜이 사용되는지를 나타내므로 대상 호스트의 IP 계층은 데이터 부분을 어떤 처리 프로세스로 넘겨야 하는지 알 수 있습니다.

(10) 첫 번째 체크섬은 16자리를 차지합니다. 이 필드는 데이터그램의 헤더만 확인하고 데이터 부분은 확인하지 않습니다. 이는 데이터그램이 라우터를 통과할 때마다 라우터가 헤더 체크섬을 다시 계산해야 하기 때문입니다(수명, 플래그, 조각 오프셋 등과 같은 일부 필드가 변경될 수 있음). 데이터의 일부를 확인하지 않으면 계산 노력이 줄어듭니다.

(11) 소스 IP 주소는 32비트를 차지합니다.

(12) 대상 IP 주소는 32비트를 차지합니다.

2. 조각화 설명

조각화란 전송하려는 데이터가 최대 전송 단위(MTU)보다 큰 경우 여러 개의 패킷으로 나누어 하나씩 상대방에게 전송해야 함을 의미합니다. . TCP에 대해 이야기할 때 MSS에 관해서는 많은 사람들이 이를 구별하지 못합니다. 아래 사진을 보면 완전히 구별할 수 있을 것 같습니다.

개인적으로 데이터가 TCP 프로토콜을 통해 전송되면 IP 계층에 도달하면 조각화가 필요하지 않다고 생각합니다. 조각화는 UDP 프로토콜을 통해 대용량 데이터를 전송할 때만 필요합니다.

예: UDP 프로토콜을 사용하여 10240바이트의 데이터를 전송하는 것을 볼 수 있지만, 데이터가 네트워크 계층에 제출되면 데이터가 최대 전송 단위를 초과하므로 조각화됩니다. 여러 개의 패킷으로 나누어 IP 프로토콜을 통해 상대방에게 전송합니다. 각 패킷의 최대 바이트는 MTU - IP 헤더 = 1500 - 20 = 1480입니다.

4. 이더넷 헤더