면접관: 소켓 TCP는 어떻게 연결을 끊나요?

• 머리말

• 소켓이란?

• 소켓 실행 프로세스

• TCP 기반

• UDP 기반

• S 소켓 TCP는 어떻게 설정되나요? 인연

• 세번 핸드셰이크는 소켓의 어떤 기능에서 발생하나요?

• 소켓 TCP 연결은 어떻게 끊어지나요?

  인터넷 하면 누구나 당연히 TCP, UDP, HTTP, three-handle-four를 떠올리겠죠? -wave 등 그러나 소켓에 관해서는 모두가 약간 혼란스러울 수 있습니다. 그들은 그것이 네트워크에서 사용될 것이라는 것만 알고 있지만 소켓이 정확히 무엇입니까? 네트워크가 소켓과 분리될 수 없는 이유는 무엇입니까?

• 소켓이란?

소켓은 실제로 소켓입니다. 대부분의 사람들은 소켓을 사용하여 간단한 네트워크 통신을 구현할 수 있다고 생각하지만, 소켓이 구체적으로 어떤 문제를 해결합니까? "

Socket은 실제로 애플리케이션 계층과 전송 계층 사이의 제품입니다. 이는 전송 계층의 많은 복잡한 작업을 몇 가지 간단한 인터페이스로 캡슐화합니다. 애플리케이션 계층은 이를 호출하여 네트워크에서 프로세스 통신을 실현합니다. 소켓은 포트 통신을 개발하기 위한 도구로 하위 수준입니다.

소켓의 기능은 실제로 식기 세척기와 유사합니다(네트워크 통신). 소켓이 없으면 수동으로 설거지를 해야 할 수도 있지만(전송 계층과 애플리케이션 계층 사이의 다양한 API를 수동으로 호출) 스위치를 클릭하고 기간을 조정하기만 하면 됩니다(API는 캡슐화되어 있음). 필요하지 않지만 그렇지 않으면 식기 세척(애플리케이션 계층과 전송 계층 간의 상호 작용)이 매우 번거로워집니다.

완전한 네트워크 통신은 물리적 전송 계층의 네트워크 케이블과 네트워크 카드를 거쳐야 합니다. 네트워크 전송 계층의 IP 프로토콜은 데이터를 전송할 시스템을 알 수 있지만 물리적 전송 계층에서는 다르게 실행됩니다. 컴퓨터 시스템 프로세스, 그러면 네트워크 카드의 네트워크 데이터가 어떤 프로세스에 사용되는지 식별하는 방법은 실제로 소켓이 해결하도록 설계된 것입니다.

소켓은 "TCP/IP 또는 UDP/IP 프로토콜의 캡슐화"입니다. 소켓 자체는 실제로 호출 인터페이스입니다. 이 인터페이스를 통해 네트워크 애플리케이션을 개발할 때 기본 레이어가 어떻게 구현되는지 걱정할 필요가 없어 개발의 어려움이 줄어듭니다.

Socket 실행 프로세스

based on TCP

Server

• socket(): 소켓 생성을 의미하며, 맨 아래 레이어는 소켓을 나타내는 파일 설명자를 생성합니다. 소켓
• bind(): 서비스를 바인딩하는 데 사용되는 포트와 주소는 클라이언트가 연결할 때 지정해야 하기 때문에 일반적으로 여기에서 고정됩니다.
• listen(): 바인딩이 완료된 후 Listen이 모니터링합니다. 이 포트의 데이터 패킷
• accept(): 스위치와 동일하며 요청을 수락할 준비가 되었지만 클라이언트 연결이 성공할 때까지 차단됩니다.
• read(): 내용을 읽습니다. sent by the client
• write(): 클라이언트는 반환될 데이터를 씁니다
• close(): 연결 끊기, "wave four times"

Client

• 소켓(): 소켓 생성을 의미하며, 맨 아래 레이어는 소켓을 나타내는 파일 설명자를 생성합니다.
• connet(): 지정된 주소에 연결하는 것을 의미합니다. 그 전에 자체 포트인 tcp의 을 생성합니다. "3방향 핸드셰이크가 여기서 시작됩니다" 의
• write(): 클라이언트가 보낼 데이터를 씁니다
• read(): 클라이언트가 서버를 읽습니다. 반환된 데이터
• close() : 연결 끊기, "4번 웨이브", 클라이언트에게 연결 끊김 정보 보내기

UDP 기반

사실, 둘은 비슷합니다. 순서도를 보면 알 수 있습니다.

UDP는 Stateless이므로 연결이 없습니다. 그리고 Recvfrom() 메소드를 호출한 후 클라이언트의 요청을 수신하고 정보가 수신될 때까지 차단합니다. 소켓 TCP는 어떻게 연결을 설정합니까? 그 유명한 삼자악수

• 첫 번째 핸드쉐이크: A의 TCP 프로세스는 전송 제어 블록 TCB를 생성한 다음 B에게 연결 요청 세그먼트를 보냅니다. 그런 다음 동기화 비트 SYN을 1로 설정하고 초기 시퀀스 번호 seq=x를 선택합니다. 이때 클라이언트 A는 SYN-SENT(동기화 전송됨) 상태로 들어갑니다.
• 두 번째 핸드셰이크: B는 연결 요청 세그먼트를 수신하고 연결 설정에 동의하면 A에게 확인 메시지를 보냅니다. 확인 메시지 세그먼트에는 동기화 비트 SYN=1, 확인 비트 ACK=1, 확인 번호 ack=x+1, 초기 시퀀스 번호 seq=y도 이때 서버 B가 스스로 선택됩니다. SYN-RCVID 상태.
• 세 번째 악수: A가 B의 확인을 받은 후 B에게 확인을 보냅니다. 확인 메시지 ACK=1, 확인 번호 ack=y+1. 이때 A는 ESTAB-LISHED 상태로 진입한다. B도 A의 확인을 받으면 ESTAB-LISHED 상태로 들어갑니다. 연결이 설정되었습니다

소켓의 어떤 기능에서 3방향 핸드셰이크가 발생합니까?

• 클라이언트가 연결을 호출하면 연결 요청이 트리거되고 SYN 신호가 소켓으로 전송됩니다. 이때 연결은 차단 상태에 들어갑니다.
• 서버는 연결 요청, 즉 SYN을 수신하고 이를 수신하기 위해 accept 함수를 호출한 후 차단 상태에 들어갑니다. 소켓, 바인드, 청취 기능을 사용하고 관련 syn 및 ack 신호를 반환합니다
• 이 때 클라이언트는 서버로부터 정보를 수신하고 차단 상태가 해제됩니다. ack 신호가 서버로 전송됩니다.
• 서버가 ack를 수신하고 연결을 완료합니다.

그 후 connect()가 실행되고 서버는 클라이언트에 데이터를 보냅니다.

소켓 TCP는 어떻게 연결을 끊나요?

• 첫 번째 웨이브: A는 먼저 연결 해제 메시지 세그먼트, 세그먼트 헤더의 종료 제어 비트 FIN=1, 시퀀스 번호 seq=u(동일)를 보냅니다. A의 앞쪽으로 전송된 데이터의 마지막 시퀀스 번호가 1씩 증가한 후 A는 FIN-WAIT-1(종료 대기 1) 상태에 들어가 B의 확인을 기다립니다.
• 두 번째 흔들기: B는 A의 연결 해제 메시지 세그먼트를 받은 후 즉시 확인 메시지 세그먼트를 보냅니다. 확인 번호 ack=u+1, 시퀀스 번호 seq=v(마지막 시퀀스 번호와 동일) 추가 1) 전에 B가 보낸 데이터는 B가 CLOSE-WAIT(닫기 대기) 상태로 들어갑니다.
• 세 번째 물결: A는 B의 확인 메시지 세그먼트를 수신한 후 FIN-WAIT-2(종료 대기 2) 상태에 진입하고 B가 연결 해제 메시지 세그먼트를 보낼 때까지 계속 기다립니다.
• B가 전송할 데이터가 없으면 B는 A에게 연결 해제 메시지 세그먼트를 전송합니다. 세그먼트 헤더의 종료 제어 비트 FIN=1, 시퀀스 번호 seq=w(일부 데이터는 반 폐쇄 상태에서 전송될 수 있음) , 확인번호 ack=u+ 1. 이때 B는 LAST-ACK(마지막 확인) 상태로 진입하여 A의 확인을 기다린다.
• 네 번째 웨이브: A는 B의 연결 해제 메시지 세그먼트를 수신하고 확인을 보냅니다. 확인 세그먼트의 확인 비트는 ACK=1, 확인 번호 ack=w+1, 시퀀스 번호 seq=u+입니다. 1; 그 다음 A TIME-WAIT(시간 대기) 상태로 들어갑니다. B가 확인 세그먼트를 다시 수신하면 B는 CLOSED 상태로 들어갑니다.

네 번째 웨이브 이후 2MSL을 기다리는 이유

먼저 2MSL의 시간은 클라이언트(A)가 FIN을 받고 ACK를 보내는 순간부터 시작됩니다. TIME-WAIT 시간 내에 클라이언트(A)의 ACK가 서버(B)로 전송되지 않아 클라이언트(A)는 서버(B)가 재전송한 FIN 메시지를 수신하면 2MSL 시간은 다음과 같습니다. 초기화. 2MSL을 기다리는 이유는 다음과 같습니다

• 1. 원래 연결의 데이터 패킷이 사라집니다
• B가 자체 ACK를 받지 못하면 타임아웃이 발생하고 A가 재전송된 FiN을 받습니다. FIN을 다시 전송하고
• B가 ACK를 받으면 더 이상 메시지를 보내지 않습니다.

마지막 웨이브 이후 A는 B가 메시지를 받았는지 알 수 없습니다. ACK를 포함하여 A는 위의 두 상황 모두를 기다려야 하며 최악의 시나리오를 처리하기 위해 두 상황의 대기 시간의 최대값을 취하려면 최악의 시나리오는 대상 ACK 메시지의 최대 생존 시간입니다. .(MSL) + 수신 FIN 메시지의 최대 생존 시간(MSL)입니다. 이는 정확히 2MSL이며, 원래 연결된 데이터 패킷이 네트워크에서 사라지도록 만드는 데 충분한 시간입니다.

• 2. 연결을 올바르게 종료하려면 서버에서 ACK를 수신할 수 있는지 확인하세요.

이 ACK가 손실되어 서버가 FIN-ACK 확인 메시지를 받지 못할 수 있기 때문입니다. 클라이언트가 2MSL을 기다리지 않고 ACK를 보낸 후 바로 닫기를 해제한다고 가정해 보겠습니다. 일단 ACK가 손실되면 서버는 정상적으로 닫힌 연결 상태로 들어갈 수 없습니다.

위 내용은 면접관: 소켓 TCP는 어떻게 연결을 끊나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!