24.07.29 day35 소켓, TCP/UDP

웹소켓과 소켓 통신

소켓과 포트의 차이가 무엇인가요?

소켓 (Socket)

소켓은 네트워크 통신의 종단점으로, 두 시스템 간의 데이터 전송을 가능하게 한다. 소켓은 IP 주소와 포트 번호를 결합한 것으로, 네트워크 상의 특정 프로세스와 통신하기 위한 인터페이스이다.

1. IP 주소: 네트워크 상의 특정 장치(호스트)를 식별
2. 포트 번호: 장치 내의 특정 애플리케이션(프로세스)을 식별
3. 프로토콜: TCP, UDP와 같은 통신 방식

소켓은 클라이언트와 서버 간의 연결을 설정하고, 데이터 전송 및 수신을 관리하는 역할을 하며, 소켓 프로그래밍에서는 소켓을 생성하고, 특정 주소와 포트에 바인딩한 후, 연결을 수립하고 데이터를 주고받는다.

 

포트 (Port)

포트는 네트워크에서 특정 프로세스를 식별하는 숫자이며, 포트 번호는 IP 주소와 결합하여 특정 서비스나 애플리케이션을 지칭한다. 포트 번호는 0에서 65535까지 사용할 수 있다.

1. 잘 알려진 포트 (Well-Known Ports): 0-1023, 주로 HTTP(80), HTTPS(443), FTP(21) 등의 표준 서비스에 사용된다.
2. 등록된 포트 (Registered Ports): 1024-49151, 특정 애플리케이션이나 서비스에 할당된다.
3. 동적/사설 포트 (Dynamic/Private Ports): 49152-65535, 주로 클라이언트 측에서 임시로 사용된다.

차이점

• 기능적 차이
  • 소켓은 네트워크 통신을 위한 종단점을 의미하며, IP 주소와 포트 번호를 포함한다.
  • 포트는 특정 네트워크 애플리케이션을 식별하는 숫자이다.
• 구성 요소
  • 소켓은 IP 주소, 포트 번호, 그리고 통신 프로토콜로 구성된다.
  • 포트는 단순히 숫자로, 특정 프로세스나 서비스를 식별한다.
• 역할:
  • 소켓은 클라이언트와 서버 간의 연결을 설정하고 데이터를 송수신하는 역할을 한다.
  • 포트는 어떤 프로세스가 통신에 사용되는지를 지정한다.

---

여러 소켓이 있다고 할 때, 이 소켓들의 포트 번호는 모두 다른가요?

소켓들의 포트 번호는 종류와 용도에 따라 다르다.

 

서버 소켓

서버 소켓은 클라이언트의 연결을 기다리는 소켓이다. 일반적으로 서버 소켓은 특정 IP 주소와 포트 번호에 바인딩되며, 이 포트 번호는 해당 서버에서 고유해야 한다.

예를 들어, 하나의 서버에서 HTTP 서비스를 제공하는 소켓이 포트 80에 바인딩되어 있다면, 같은 서버에서 다른 서버 소켓이 동일한 포트 번호 80에 바인딩될 수 없다.

 

클라이언트 소켓

클라이언트 소켓은 서버에 연결을 요청하는 소켓이다. 클라이언트 소켓도 포트를 사용하지만, 이 포트 번호는 주로 임시적으로 할당되며, 동적/사설 포트 범위(49152-65535) 내에서 사용된다.

클라이언트 소켓은 동일한 서버와 통신할 때 서로 다른 소스 포트 번호를 가질 수 있다.

 

같은 포트 번호를 공유하는 경우

특정 상황에서는 여러 소켓이 같은 포트 번호를 공유할 수 있다.

1. 다중 클라이언트 연결: 서버 소켓은 동일한 포트 번호에서 여러 클라이언트 연결을 수락할 수 있다. 이 경우 서버는 포트 번호가 동일하지만, 각 클라이언트와의 연결은 소켓의 IP 주소와 소스 포트 번호가 달라서 구분할 수 있다.
2. 소켓 옵션: SO_REUSEADDR와 같은 소켓 옵션을 사용하면, 동일한 포트 번호를 여러 소켓에서 재사용할 수 있는데, 이는 주로 서버 소프트웨어가 재시작될 때 이전 소켓이 완전히 종료되지 않은 상태에서도 포트를 재사용할 수 있게 해준다.

요약

• 서버 소켓: 동일 서버 내에서 고유한 포트 번호를 사용해야 한다.
• 클라이언트 소켓: 동일 서버에 여러 연결을 만들 때 임시 포트를 사용하며, 각각의 소켓은 다른 소스 포트 번호를 가질 수 있다.
• 특정 상황에서의 공유: 다중 클라이언트 연결 또는 특정 소켓 옵션을 사용하여 같은 포트 번호를 공유할 수 있다.

---

TCP/UDP 프로토콜

TCP와 UDP의 차이에 대해 설명해주세요.

TCP (Transmission Control Protocol)

• 연결 지향적: 데이터를 전송하기 전에 연결을 설정한다.
• 신뢰성: 데이터 전송의 신뢰성을 보장하고, 손실된 패킷을 자동으로 재전송한다.
• 흐름 및 혼잡 제어: 데이터 흐름과 네트워크 혼잡을 관리한다.
• 순서 보장: 데이터 패킷의 순서를 보장한다.
• 헤더 크기: 20바이트 이상
• 사용 사례: 신뢰성이 중요한 애플리케이션 (예: 웹 브라우징, 이메일, 파일 전송)

UDP (User Datagram Protocol)

• 비연결 지향적: 연결 설정 없이 데이터를 전송한다.
• 신뢰성 부족: 데이터 전송의 신뢰성을 보장하지 않으며, 손실된 패킷을 재전송하지 않는다.
• 흐름 및 혼잡 제어 없음: 데이터 흐름과 네트워크 혼잡을 관리하지 않는다.
• 순서 보장 없음: 데이터 패킷의 순서를 보장하지 않는다.
• 헤더 크기: 8바이트
• 사용 사례: 속도가 중요한 애플리케이션 (예: 실시간 스트리밍, 온라인 게임, VoIP).

핵심 차이점

• 신뢰성: TCP는 신뢰성을 보장, UDP는 보장하지 않음
• 연결 방식: TCP는 연결 지향적, UDP는 비연결 지향적
• 순서 및 제어: TCP는 순서와 흐름/혼잡 제어를 제공, UDP는 제공하지 않음
• 사용 목적: TCP는 신뢰성이 필요한 경우, UDP는 속도가 중요한 경우

---

Checksum이 무엇인가요?

체크섬(Checksum)

체크섬은 데이터 전송 중에 발생할 수 있는 오류를 검출하기 위해 사용되는 값이다. 송신 측에서 데이터를 일정한 방식으로 계산하여 체크섬 값을 생성하고, 이 값을 데이터와 함께 전송하는데, 수신 측에서 동일한 계산을 수행하여 수신된 데이터의 체크섬 값과 비교함으로써 데이터의 무결성을 확인한다.

 

작동 방식

1. 체크섬 생성: 송신자가 데이터를 일정한 크기의 블록으로 나누어 더하거나 다른 알고리즘을 통해 체크섬 값을 계산한다.
2. 체크섬 전송: 송신자가 원본 데이터와 함께 체크섬을 전송한다. 예시로 네트워크 패킷의 끝에 체크섬 값을 추가한다
3. 체크섬 검증: 수신자가 데이터를 받아 동일한 방식으로 체크섬을 계산하고, 전송된 체크섬과 비교하여 데이터의 무결성을 확인한다.

사용 예

 

• 네트워크 프로토콜: TCP와 UDP 같은 프로토콜에서는 전송되는 데이터의 무결성을 확인하기 위해 체크섬을 사용하며, 각 패킷의 헤더에 체크섬 필드가 포함되어 있다.
• 파일 전송 및 저장: 파일을 다운로드하거나 저장 매체에서 데이터를 읽을 때, 데이터가 손상되었는지 확인하기 위해 체크섬이 사용된다. 예를 들어, 파일을 다운로드할 때 제공되는 MD5나 SHA-1 해시 값이 체크섬의 한 형태

 

한계

체크섬은 간단하고 빠른 오류 검출 방법이지만, 일부 유형의 오류는 검출되지 않을 수 있기 때문에 완벽하지 않다. 예를 들어, 데이터의 여러 비트가 변경되었지만 그 합이 동일한 경우 체크섬 값은 변하지 않는다.

더 복잡한 오류 검출 및 수정 방법으로는 CRC(Cyclic Redundancy Check)나 ECC(Error-Correcting Code) 등이 있다.

체크섬은 데이터 무결성을 보장하는 기본적인 방법으로 널리 사용된다.

---

TCP와 UDP중 어느 프로토콜이 Checksum을 수행할까요?

TCP와 UDP 모두 체크섬을 사용하여 데이터의 무결성을 검증하며, 두 프로토콜 모두 데이터 전송 중 오류를 검출하기 위해 체크섬 필드를 포함하고 있다.

 

TCP (Transmission Control Protocol)

• 체크섬 필드: TCP 헤더에는 16비트의 체크섬 필드가 포함되어 있다.
• 역할
  • 송신자는 데이터와 TCP 헤더를 포함한 전체 TCP 세그먼트의 체크섬을 계산하여 헤더의 체크섬 필드에 기록한다
  • 수신자는 수신된 세그먼트에 대해 동일한 계산을 수행하고, 수신된 체크섬 값과 비교한다. 체크섬 값이 일치하지 않으면 데이터가 손상된 것으로 간주하고 해당 세그먼트를 폐기한다.

UDP (User Datagram Protocol)

• 체크섬 필드: UDP 헤더에도 16비트의 체크섬 필드가 포함되어 있다.
• 역할
  • UDP도 데이터그램의 무결성을 확인하기 위해 체크섬을 사용하며, UDP 체크섬은 선택사항이지만, IPv6에서는 필수이다.
  • 송신자는 데이터와 UDP 헤더를 포함한 전체 UDP 데이터그램의 체크섬을 계산하여 헤더의 체크섬 필드에 기록한다.
  • 수신자는 수신된 데이터그램에 대해 동일한 계산을 수행하고, 수신된 체크섬 값과 비교한다. 체크섬 값이 일치하지 않으면 데이터가 손상된 것으로 간주하고 해당 데이터그램을 폐기한다.

요약

• TCP와 UDP 모두 체크섬을 사용
• TCP: 16비트 체크섬 필드를 사용하여 TCP 세그먼트의 무결성을 검증
• UDP: 16비트 체크섬 필드를 사용하여 UDP 데이터그램의 무결성을 검증(IPv4에서는 선택사항, IPv6에서는 필수).

---

TCP가 신뢰성을 보장하는 방법에 대해 설명해주세요.

TCP의 신뢰성 보장 방법

1. 연결 설정: 3-way handshake로 연결을 설정한다.
2. 데이터 분할 및 재조립: 데이터를 세그먼트로 나누어 전송하고, 수신 측에서 재조립한다.
3. 순서 제어: 시퀀스 번호를 사용해 데이터의 순서를 보장한다.
4. 오류 검출: 체크섬을 사용해 데이터 오류를 검출한다.
5. 확인 응답(ACK): 수신 측에서 ACK 패킷을 보내 수신을 확인한다.
6. 재전송: 일정 시간 내 ACK를 받지 못하면 데이터를 재전송한다.
7. 흐름 제어: 수신 윈도우 크기를 통해 전송 속도를 조절한다.
8. 혼잡 제어: 네트워크 혼잡을 감지하고 전송 속도를 조절한다.

이러한 메커니즘으로 TCP는 신뢰성 있는 데이터 전송을 보장한다.

---

왜 HTTP는 TCP를 사용하나요?

HTTP가 TCP를 사용하는 이유

1. 신뢰성 있는 데이터 전송
   • HTTP는 웹 페이지와 같은 중요한 데이터를 전송하는 데 사용된다.
   • TCP는 데이터 전송 중 오류를 검출하고 수정하는 기능을 제공하여 데이터가 정확히 도착하도록 보장한다.
2. 연결 지향적 특성
   • HTTP는 클라이언트와 서버 간의 연결을 유지하며 여러 요청과 응답을 처리한다.
   • TCP의 연결 지향적 특성은 이러한 지속적인 연결을 지원하고 안정적인 통신을 제공한다.
3. 데이터 순서 보장
   • TCP는 데이터 패킷의 순서를 보장한다.
   • 웹 페이지는 여러 개의 리소스(예: HTML, CSS, 이미지 등)로 구성되어 있으며, TCP는 이들 리소스가 올바른 순서로 수신되도록 보장한다.
4. 흐름 제어
   • TCP는 수신 측의 버퍼를 관리하여 오버플로우를 방지한다.
   • HTTP의 데이터 전송 과정에서 클라이언트와 서버 간의 원활한 데이터 흐름을 유지하는 데 도움이 된다.
5. 혼잡 제어
   • TCP는 네트워크 혼잡 상태를 모니터링하고 전송 속도를 조절한다.
   • 이는 네트워크의 과부하를 방지하고 안정적인 데이터 전송을 지원한다.
6. 연속적인 데이터 전송 지원
   • HTTP는 클라이언트와 서버 간의 지속적인 데이터 전송을 필요로 한다.
   • TCP는 이러한 연속적인 전송을 효율적으로 지원하여 HTTP의 요청/응답 모델에 적합하다.

이러한 특성 덕분에 TCP는 HTTP가 필요로 하는 신뢰성, 연결 유지, 데이터 순서 보장, 흐름 및 혼잡 제어 기능을 제공하여 안정적이고 일관된 웹 페이지 전송을 보장한다.

---

브라우저는 어떤 서버가 TCP를 쓰는지, UDP를 쓰는지 어떻게 알 수 있나요?

브라우저는 서버가 TCP를 사용하는지 UDP를 사용하는지 직접적으로 알아내기보다는, 사용자가 요청하는 프로토콜에 따라 적절한 프로토콜을 자동으로 사용한다.

 

브라우저의 프로토콜 사용 방식

1. HTTP/HTTPS 요청
   • TCP 사용: 웹 브라우저는 HTTP(및 HTTPS) 요청을 할 때 TCP를 사용하는데, 이는 웹 프로토콜의 표준이다.
   • 동작
     • 브라우저가 HTTP 또는 HTTPS URL을 요청하면, 브라우저는 자동으로 TCP 연결을 설정하고, 연결이 설정된 후 HTTP/HTTPS 요청을 전송한다.
     • 이 과정에서 브라우저는 명시적으로 TCP를 사용한다는 것을 알고 있으며, 사용자나 서버가 이를 변경할 필요는 없다.
2. DNS 조회
   • UDP 사용: DNS 요청은 기본적으로 UDP를 사용하는데, DNS는 짧은 쿼리와 응답이 빈번히 발생하기 때문에 UDP가 적합하다.
   • 동작
     • 브라우저가 웹사이트의 도메인 이름을 IP 주소로 변환하기 위해 DNS 쿼리를 보낼 때 UDP를 사용한다.
     • 만약 DNS 응답이 너무 크거나 UDP에서 문제가 발생하면, TCP를 사용하는 DNS 요청(EDNS)으로 자동으로 전환될 수 있다.
3. 기타 프로토콜
   • QUIC
     • 최신 웹 기술에서는 QUIC이라는 프로토콜이 사용되며, QUIC은 UDP를 기반으로 하지만, TCP의 많은 기능(예: 연결 설정, 흐름 제어 등)을 구현하여 성능과 신뢰성을 개선한다.
     • 브라우저는 QUIC을 지원하는 서버와 연결할 때 UDP를 사용하지만, 프로토콜 자체의 세부 사항은 브라우저에 의해 관리된다.

프로토콜 결정 과정

• URL 스킴
  • 사용자가 입력한 URL에 따라 브라우저는 사용하는 프로토콜을 결정한다.
  • 예를 들어, http:// 또는 https://로 시작하는 URL은 TCP를 사용하지만, dns:// 같은 URL은 DNS 조회로 UDP를 사용한다.(단, 실제 DNS URL은 일반적으로 사용되지 않음).
• 브라우저의 내부 로직
  • 브라우저는 다양한 프로토콜에 대한 내장 로직을 가지고 있으며, 각각의 프로토콜이 요구하는 네트워크 전송 방식을 자동으로 선택한다.
  • 이 과정은 사용자가 직접 관여하지 않고 브라우저가 자동으로 처리한다.

요약

• HTTP/HTTPS 요청은 TCP를 사용하며, 브라우저는 HTTP/HTTPS 요청을 자동으로 TCP를 통해 전송한다.
• DNS 조회는 기본적으로 UDP를 사용하지만, 필요에 따라 TCP를 사용할 수도 있다.
• QUIC과 같은 최신 기술은 UDP를 기반으로 하지만, TCP의 기능을 제공하여 성능을 개선한다.

브라우저는 사용자가 요청한 프로토콜과 목적에 따라 적절한 전송 방식을 자동으로 선택하기 때문에, 브라우저와 서버 간의 통신 프로토콜을 직접 관리할 필요는 없다.