TIL

21일차 발표

김영재0412 2022. 5. 16. 17:05
  • [C511] 소켓과 포트의 특징을 작성하고, 그 차이점을 설명하세요.

포트(Port)

네트워크 상에서 통신하기 위해서 호스트 내부적으로 프로세스가 할당받아야 하는 고유한 숫자이다. 한 호스트 내에서 네트워크 통신을 하고 있는 프로세스를 식별하기 위해 사용되는 값이므로, 기본적으로는 같은 호스트 내에서 서로 다른 프로세스가 같은 포트 넘버를 가질 수 없다. 

 

소켓(Socket)

프로세스가 드넓은 네트워크 세계로 데이터를 내보내거나 혹은 그 세계로부터 데이터를 받기 위한 실제적인 창구 역할을 한다. 그러므로 프로세스가 데이터를 보내거나 받기 위해서는 반드시 소켓을 열어서 소켓에 데이터를 써보내거나 소켓으로부터 데이터를 읽어들여야 한다. 소켓을 열기 위해선 호스트에 할당된 IP 주소, 포트 넘버, 프로토콜(Protocol) 등이 필요하며, 이 세 가지가 소켓을 정의한다

 

차이점

소켓은 인터넷 프로토콜을 기반으로 하는 컴퓨터 네트워크에서 발생하는 양방향 통신의 끝점이며 포트는 임시 파일이나 저장소를 사용하지 않고 데이터를 교환하는 데 사용할 수 있는 논리적 데이터 연결입니다. 소켓은 포트와 연결되며 포트와 연결된 여러 소켓이 있을 수 있습니다. 들어오는 연결을 기다리는 포트와 연결된 단일 수동 소켓이 있을 수 있습니다. 또한 해당 포트에서 열려 있는 연결에 해당하는 활성 소켓이 여러 개 있을 수 있습니다.

 

 

 

 

 

 

https://www.differencebetween.com/difference-between-socket-and-vs-port/

https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=myca11&logNo=221389847130 

 

 

 

 

 

 

 

 

 

  • [C512] HTTP 버전별 특징과 차이점을 설명하세요. 

 

HTTP/0.9 (1991년)

HTTP/1.0 (1996년)

HTTP/1.1 (1997년) : 가장 많이 사용중이다.{

RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

}

HTTP/2.0 (2015년) : HTTP 1.1의 성능 개선 및 확장

HTTP/3.0 (진행중)

 

 

HTTP/0.9

  • HTTP 초기 버전을 구분하기 위해 부르는 버전 (1991년)
  • 요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재
  • 응답도 극도로 단순 (파일 내용 자체로만 구성)
  • HTTP 헤더도 없고, HTML파일만 전송 가능했던 것이 특징

HTTP/1.0

  • 특징
    • HTTP 헤더(header) 개념이 도입되어 요청과 응답에 추가되며, 메타데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선됨 (1996년)
    • 버전 정보와 요청 method가 함께 전송되기 시작
    • 상태 코드 라인도 응답의 시작부분에 추가되어 브라우저 요청의 성공과 실패를 파악 가능해짐
      (해당 결과에 대한 로컬 캐시 갱신 등의 사용이 가능해짐)
    • Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐
  • 한계
    • 커넥션 하나당 요청 하나와 응답 하나만 처리 가능했음
      -> 지금 생각해보면 매우 비효율적인 동작으로 보이며, 서버 부하도 문제
      -> HTTP 1.1에서 개선

 

HTTP/1.1

 

  • 특징
    • 1997년 등장
    • Persistent Connection 추가
      • 지정한 timemout 동안 커넥션을 닫지 않는 방법을 통해 커넥션의 사용성이 높아짐
    • Pipelining 추가
      • 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식이 등장
      • 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
      • 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아니다 (multiplexing 되지는 않음)
  • 한계
    • Head Of Line Blocking (HOL)
      : 결국 앞 요청의 응답이 너무 오래걸리면 뒤 요청은 Blocking 되어버림
    • Header 구조의 중복
      : 연속된 요청의 헤더의 많은 중복이 발생

 

 

HTTP/2.0

 

  • 설명
    • 기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜 (2015년 등장)
    • 표준의 대체가 아닌 확장 (표준 : HTTP 1.1)
  • 특징
    • 1) HTTP 메시지 전송 방식의 전환
    • 2) Multiplexed Streams
    • 3) Stream Prioritization
    • 4) Server Push
    • 5) Header Compression

HTTP 메시지 전송 방식의 전환

  • 기존 : 일반 텍스트 형식
  • 개선
    • Binary Framing 계층을 추가해서 보내는 메시지를 프레임(frame)이라는 단위로 분할하며 추가적으로 바이너리로 인코딩을 한다
      (바이너리 형식 사용으로 파싱속도  전송 속도가 빠르고 오류 발생 가능성이 낮아짐)

Multiplexed Streams

  • 기존 : HTTP 1.1의 Pipelining 으로 하나의 커넥션에 여러 요청이 있지만, 결국 동시에 여러 요청을 처리해 응답으로 주지는 못하였음
  • 개선
    • 구성된 연결 내에 전달되는 바이트의 양방향 흐름을 의미하는 Stream으로 요청 / 응답이 교환됨
      (하나의 커넥션 안에 여러개의 Stream 존재 가능)
    • 메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 Stream을 통해 전달
    • 즉, 프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해짐
      -> 동시에 여러 요청을 처리하는 것이 가능해짐
      -> Stream을 통해서 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 자연스럽게 해결됨

 

Stream Prioritization

  • 리소스간 우선순위를 설정하는 기능
  • Stream에 우선순위를 부여해서 인터리빙되고 전달하는 것이 가능해짐

 

Server Push

  • 단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 Server에서 client에게 필요한 추가적인 리소스를 push해주는 기능

 

Header Compression

  • 기존 : 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이발생했음
  • 개선
    • 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드를 감소
    • 1) 전송되는 헤더 필드를 static dynamic table로 서버에서 유지
    • 2) 이전에 표시된 헤더를 제외한 필드를 허프만(huffman) 인코딩을 수행해서 데이터를 압축

 

[ HTTP 2.0 한계 ]

  • 각 요청마다 Stream으로 구분해서 병렬적으로 처리하지만,
    결국 이에는 TCP 고유의 HOL Blocking이 존재
  • 왜냐하면, 서로 다른 Stream이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생되기 때문
  • 즉, 이러한 TCP의 태생적인 HOL Blocking을 해결하기 위해 QUIC / HTTP3.0이 등장

 

 

HTTP/3.0

  • QUIC을 기반으로 나온 새로운 HTTP 메이저 버전
  • QUIC ?
    • Google에서 개발한 UDP 기반의 전송 프로토콜 (Quick UDP Internet Connections)
    • Google에서 TCP의 구조적 문제로 성능 향상이 어렵다고 판단하여 UDP 기반을 선택
    • QUIC은 TCP의 3-way handshake과정을 최적화 하는 것에 초점을 두고 개발됨
    • QUIC은 TCP의 Stream은 하나의 chain으로 연결되는 것과 다르게 각 Stream당 독립된 Stream chain을 구성하여 TCP HOL Blocking을 해결하였다

 

 

 

https://velog.io/@neity16/HTTP-HTTP-%EB%B2%84%EC%A0%84-%EB%B3%84-%ED%8A%B9%EC%A7%95

'TIL' 카테고리의 다른 글

22일차 네트워크 기초  (0) 2022.05.17
22일차 발표  (0) 2022.05.17
21일차 네트워크 기초  (0) 2022.05.16
15일차 WAS와 Web Server  (0) 2022.05.06
14일차 REST API  (0) 2022.05.04