TCP/IP, HTTP, 소켓의 차이점

네트워크는 아래에서 위로

물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 프리젠테이션 계층, 애플리케이션 계층으로 구분됩니다.

사전 이해를 통해 IP 프로토콜은 네트워크 계층, TCP 프로토콜은 전송 계층, HTTP 프로토콜은 애플리케이션 계층에 해당하는 것으로 알고 있습니다.

이 세 가지는 다음과 같습니다. 본질적으로 비교할 수 없습니다.

소켓은 TCP/IP 프로토콜의 캡슐화 및 응용 프로그램입니다(프로그래머 수준).

TPC/IP 프로토콜은 주로 네트워크에서 데이터가 전송되는 방식을 해결하는 전송 계층 프로토콜이라고 할 수 있습니다.

그리고 HTTP는 주로 다음 문제를 해결하는 애플리케이션 계층 프로토콜입니다. 데이터를 패키징하는 방법.

TCP/IP와 HTTP 프로토콜의 관계와 관련하여 네트워크는 비교적 이해하기 쉬운 소개를 가지고 있습니다.

"데이터를 전송할 때 (전송 계층)만 사용할 수 있습니다. 하지만 이 경우 애플리케이션 계층이 없으면 데이터 내용을 식별할 수 없습니다.

전송되는 데이터를 의미있게 만들려면 다음과 같은 애플리케이션 계층 프로토콜을 사용해야 합니다. HTTP, FTP, TELNET 등을 사용하여 자체 애플리케이션 계층 프로토콜을 정의할 수도 있습니다.

WEB는 HTTP 프로토콜을 애플리케이션 계층 프로토콜로 사용하여 HTTP 텍스트 정보를 캡슐화한 다음 TCP/IP를 전송 계층으로 사용합니다.

우리가 흔히 말하는 소켓이란 사실 TCP/IP 프로토콜을 캡슐화한 것입니다. 소켓 자체는 프로토콜이 아니라 호출입니다. 인터페이스(API).

Socket을 통해 TCP/IP 프로토콜을 사용할 수 있습니다.

사실 소켓이 꼭 TCP/IP 프로토콜과 연관되어 있는 것은 아닙니다.

소켓 프로그래밍 인터페이스를 설계할 때 다른 네트워크 프로토콜에도 적용할 수 있을 것으로 기대되었습니다.

따라서 소켓의 출현은 프로그래머가 TCP/IP 프로토콜 스택을 보다 쉽게 ​​사용할 수 있도록 해줄 뿐입니다.

따라서 이는 TCP/IP 프로토콜 스택을 추상화한 것입니다. 우리가 알고 있는 가장 인기 있는 인터페이스입니다. 생성, 수신, 연결, 수락, 전송, 읽기, 쓰기 등과 같은 기본 기능 인터페이스입니다.

인터넷에는 소켓과 TCP/IP 프로토콜의 관계를 더 쉽게 이해할 수 있는 설명이 있습니다.

"TCP/IP는 운영 메커니즘과 마찬가지로 프로토콜 스택일 뿐입니다.

이는 운영 체제가 win32 프로그래밍 인터페이스와 같은 표준 프로그래밍 인터페이스를 제공하는 것과 같습니다.

TCP/IP도 프로그램을 제공합니다. 네트워크 개발자들이 사용하는 소켓 프로그래밍 인터페이스입니다. "

TCP/IP 프로토콜에 대한 관련 정보는 너무 광범위하고 심오하다고 말할 수 없습니다. 이러한 유형의 정보에 대한 정보는 다음에서 확인하십시오. 인터넷에서 자료와 책의 수를 보면 알 수 있습니다.

공부할 고전 책(예: "TCP/IP 상세 설명: 1권, 2권, 3권")을 구입하려고 합니다. 오늘은 방금 많이 이야기한 TCP/IP 프로토콜, 즉 HTTP와 소켓을 기반으로 하는 애플리케이션과 프로그래밍 인터페이스에 대한 지식을 바탕으로 몇 가지를 요약해 보겠습니다.

CSDN에 대한 좀 더 생생한 설명이 있습니다. HTTP는 데이터를 캡슐화하거나 표시하는 특정 형식을 제공하는 자동차이고, 소켓은 네트워크 통신 기능을 제공하는 엔진입니다.

실제로 전송 계층의 TCP는 네트워크 계층의 IP 프로토콜을 기반으로 하고, 애플리케이션 계층의 HTTP 프로토콜은 전송 계층의 TCP 프로토콜을 기반으로 하며, 소켓 자체는 그렇지 않습니다. 위에서 언급한 것처럼 프로토콜은 TCP 또는 UDP 프로그래밍을 위한 인터페이스만 제공합니다.

필기시험이나 면접에서 자주 접하는 중요한 개념을 발췌, 요약하였습니다.

1. TCP 연결의 3방향 핸드셰이크란

첫 번째 핸드셰이크: 클라이언트가 서버에 syn 패킷(syn=j)을 보내고 SYN_SEND 상태로 진입하여 대기합니다.

두 번째 핸드셰이크: 서버는 syn 패킷을 수신하고 클라이언트의 SYN(ack=j+1)을 확인해야 합니다. 동시에 SYN 패킷(syn=k)도 보냅니다. ) 즉, SYN+ACK 패킷입니다. 이때 서버는 SYN_RECV 상태로 진입합니다.

세 번째 핸드셰이크: 클라이언트는 서버로부터 SYN+ACK 패킷을 수신하고 확인 패킷 ACK(ack=k)를 보냅니다. +1) 패킷이 전송된 후 클라이언트와 서버는 ESTABLISHED 상태로 들어가고 3방향 핸드셰이크가 완료됩니다.

Handshake 과정에서 전송되는 패킷에는 데이터가 포함되어 있지 않습니다. Three-Way Handshake가 완료된 후 클라이언트와 서버는 공식적으로 데이터 전송을 시작합니다.

이상적으로는 일단 TCP 연결이 설정되면 어느 쪽이든 적극적으로 연결을 종료할 때까지 TCP 연결이 유지됩니다.

연결을 끊을 때 서버와 클라이언트 모두 TCP 연결 끊기 요청을 적극적으로 시작할 수 있습니다. 연결 끊기 프로세스에는 "4방향 핸드셰이크"가 필요합니다. 프로세스는 자세히 설명되지 않으며 간의 상호 작용입니다. 서버와 클라이언트의 연결을 끊기로 최종 결정)

2. 소켓을 사용하여 네트워크 연결을 설정하는 단계

소켓 연결을 설정하려면 최소한 한 쌍의 소켓이 필요하며 그 중 하나는 다음에서 실행됩니다. 클라이언트는 ClientSocket이라고 하며 다른 하나는 서버 측에서 실행되며 ServerSocket이라고 합니다.

소켓 간의 연결 프로세스는 서버 모니터링, 클라이언트 요청, 연결 확인의 세 단계로 나누어집니다.

1. 서버 모니터링: 서버 측 소켓은 특정 클라이언트 소켓을 찾아내지 않고 연결을 기다리는 상태로, 네트워크 상태를 실시간으로 모니터링하며 클라이언트의 연결 요청을 기다리는 상태이다.

2. 클라이언트 요청: 연결을 요청하는 클라이언트의 소켓을 말하며, 연결 대상은 서버의 소켓입니다.

이렇게 하려면 클라이언트의 소켓이 먼저 연결하려는 서버의 소켓을 기술하고 서버측 소켓의 주소와 포트 번호를 지정한 다음 서버측 소켓에 연결 요청을 해야 합니다. .

3. 연결 확인: 서버 측 소켓은 클라이언트 소켓의 연결 요청을 수신하거나 수신하면 클라이언트 소켓의 요청에 응답하고 새 스레드를 설정하며 서버 측 소켓에 대한 설명 클라이언트가 이 설명을 확인하면 두 당사자 간에 공식적으로 연결이 설정됩니다.

서버 측 소켓은 계속 수신 대기 상태에 있으며 다른 클라이언트 소켓으로부터 연결 요청을 계속 수신합니다.

3. HTTP 링크의 특징

HTTP 프로토콜은 웹 네트워킹의 기본이자 휴대폰 네트워킹에 일반적으로 사용되는 프로토콜 중 하나인 Hypertext Transfer Protocol입니다. TCP 프로토콜 위에 애플리케이션을 구축하기 위한 기반입니다.

HTTP 연결의 가장 중요한 특징은 클라이언트가 보낸 각 요청마다 서버가 응답을 다시 보내야 한다는 것입니다. 요청이 완료된 후 연결이 적극적으로 해제됩니다. 연결 설정부터 연결 종료까지의 과정을 "연결"이라고 합니다.

4. TCP와 UDP의 차이점 (가장 많이 테스트했는데... 거의 실패할 것 같아요 - -\)

1. TCP는 링크 지향적이지만 네트워크는 안전하지 않음 불안정한 특성으로 인해 어떠한 핸드셰이크도 연결의 신뢰성을 보장할 수 없지만 TCP의 3방향 핸드셰이크는 연결의 신뢰성을 최소한(실제로는 상당 부분) 보장합니다.

그리고 UDP는 연결 지향적이지 않으므로 UDP는 데이터를 전송하기 전에 상대방과 연결을 설정하지 않으며, 수신된 데이터에 대한 확인 신호를 보내지 않으며, 송신 측에서는 데이터가 올바르게 수신될지 알 수 없습니다. 물론 다시 보낼 필요가 없으므로 UDP는 연결이 없는 데이터 전송 프로토콜입니다.

2. UDP의 오버헤드가 적고 데이터 전송률이 높은 것은 바로 1에서 언급한 특성 때문입니다. 송수신 데이터를 확인할 필요가 없기 때문에 UDP가 실시간 성능이 더 좋습니다.

TCP와 UDP의 차이점을 알면 TCP 전송 프로토콜을 사용하는 MSN이 UDP를 사용하여 파일을 전송하는 QQ보다 느린 이유를 이해하는 것은 어렵지 않지만 QQ 통신이 안전하지 않다는 의미는 아닙니다.

　UDP 데이터 송수신을 프로그래머가 수동으로 확인할 수 있기 때문입니다. 예를 들어 발신자는 각 데이터 패킷에 번호를 지정한 다음 수신자 등이 이를 확인합니다.

　그래도 UDP는 맨 아래 계층에 있습니다. 프로토콜의 캡슐화는 TCP와 유사한 "3방향 핸드셰이크"를 사용하지 않으므로 TCP가 달성할 수 없는 전송 효율성을 달성합니다.