[1. HTTP의 정의]
- HTTP(HyperText Transfer Protocol)
- HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜
(* 프로토콜 : 서로 다른 두 개체가 데이터를 원활히 주고받기 위한 통신 규약)
- 클라이언트-서버모델 : 리소스를 사용하는 앱(클라이언트)과 리소스가 존재하는 곳(서버)을 분리시키는 모델
- 무상태 프로토콜 : 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜
[2. HTTP Response & Request 메시지의 구조]
1. Request
(1) Request line(start line) : HTTP 메소드 + URI + HTTP 버전
- GET, POST 등의 요청이 들어감
- URL, 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수 있음
- 응답 메세지에서 써야 할 HTTP 버전을 나타냄
(2) Header : 요청의 내용을 구체화하고, 메세지 본문에 대한 설명이 들어감
- 대소문자 구분 없이, 문자열 다음에 콜론이 붙음
- General header : Header전체에 적용
- Request header : 요청의 내용을 구체화시키고 컨텍스를 제공하기도 하며 조건에 따른 제약 사항을 주기도 하면서 요청 내용을 수정
- Representation header : 메시지 데이터의 원래 형식과 적용된 인코딩을 설명
(3) Blank line : 요청에 대한 모든 메타 정보가 전송되었음을 알리는 역할/header와 body를 구분하기 위한 역할
(4)Body : 모든 요청에 본문이 들어가지는 않음(리소스를 가져오는 요청에는 본문이 필요하지 않음)
- 단일 리소스 본문 : 헤더 두 개로 정의된 단일 파일로 구성
- 다중 리소스 본문 : multipart 본문으로 구성, 파트마다 다른 정보를 포함
2. Response
(1) Status line
- 요청의 성공 여부를 나타내는 상태 코드 (일반적인 상태 코드 : 200, 404, 302)
(2) Header
- Response Header : 상태 줄에 표시되지 않는 추가 정보를 제공
- Representation Header : 메시지 데이터의 원래 형식과 적용된 인코딩 설명
- General Header : 메세지 전체에 적용됨
[3. HTTP 버전별 특징과 변화]
1. HTTP/1.0
- 한 연결 당 하나의 요청을 처리하도록 설계됨
- 서버로부터 파일을 가져올 때마다 TCP의 3-way--handshake를 계속해서 열어야 하므로, RTT 증가 야기
- RTT : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복 시간
- RTT증가를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 base64 인코딩을 사용
- 이미지 스플리팅 : 많은 이미지를 다운받게 되면 과부하가 걸리므로, 이미지가 합쳐져 있는 하나의 이미지를 다운받고 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법
- 코드압축 : 개행문자, 빈칸을 없애 코드의 크기를 최소화하는 방법
- 이미지 Base64인코딩 : 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법
2. HTTP/1.1
- 한 번 TCP를 초기화한 후, 매번 TCP연결을 하는 것이 아니라 한 번 TCP 초기화 이후에 keep alive라는 옵셥으로 여러개의 파일을 송수신할 수 있도록 바뀜 (1.1부터 표준화)
- HTTP1.0과 1.1의 비교
- 한번 3-way-handshake가 발생하면 그 다음부터는 발생하지 않는다는 장점이 있음
- 하지만 문서 안에 포함된 다수의 리소스를 처리하려면 그 개수에 비례해 대기 시간이 길어진다는 단점이 있음
- 또한 쿠키 등의 많은 메타데이터가 들어있고 압축이 되지 않아 무거움
* 3-way-handshake
- SYN(연결 요청 플래그) 단계 : 클라이언트는 서버에 클라이언트의 ISN을 담아 SYN을 보낸다. ISN은 새로운 TCP연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호를 말하며 장치마다 다르다
- SYN + ACK(응답 플래그) 단계 : 서버는 클라이언트의 SYN을 수행하고 서버의 ISN을 보내며 승인번호로 클라이언트의 ISN+1을 보낸다
- ACK단계 : 클라이언트는 서버의 ISN+1한 값인 승인번호를 담아 ACK를 서버에 보낸다
- TCP는 위와 같은 과정이 있어 신뢰성이 있는 계층이라고 말하며, UDP는 이 과정이 없기 때문에 신뢰성이 없는 과정이라고 말한다
3. HTTP/2
- HTTP/1.x보다 지연시간을 줄이고 응답 시간을 더 빠르게 할 수 있음
- 멀티플렉싱, 헤더압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜
(1) 멀티 플렉싱 : 여러개의 스트림(시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름)을 사용하여 송수신, 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미칠 뿐 나머지 스트림에는 악영향이 없음
(2) 헤더 압축 : 크기가 큰 헤더를 허프만 코딩 압축 알고리즘을 사용해 압축함 (* 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현, 진도가 낮은 정보는 비트 수를 많이 사용해 표현해서 전체 데이터 표현에 필요한 비트 양을 줄이는 원리)
(3) 서버 푸시 : 클라이언트의 요청 없이도 서버가 바로 리소스를 푸시할 수 있음 (html 파일을 요청하면, css파일도 같이 푸시해줌)
4. HTTPS
- 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP요청, 이를 통해 통신 암호화
- SSL/TLS : 전송 계층에서 보안을 제공하는 프로토콜, 클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제 3자가 메시지를 도청하거나 변조하지 못하도록 함(인터셉터 방지)
5. HTTP/3
- QUIC라는 계층 위에서 돌아가며 TCP가 아닌 UDP기반으로 돌아가기 때문에 3-way-handshake과정이 없음
- 즉 초기 연결 시 지연 시간이 감소됨
- 오류수정 매커니즘(FEC) 적용 => 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식으로, 열악한 네트워크 환경에서도 패킷 손실률이 낮음
'자유게시판 > 스터디' 카테고리의 다른 글
| [WEB] HTTP 메소드 (0) | 2024.01.02 |
|---|---|
| [Web] 구글을 주소창에 검색했을 때 화면이 나오기까지의 과정 (0) | 2024.01.01 |
| 스터디 7주차 (0) | 2023.03.26 |
| 스터디 6주차 (0) | 2023.03.09 |
| 스터디 5주차 (0) | 2023.03.03 |
