WEB/네트워크/ HTTP (HyperText Transfer Protocol)

HTTP(HyperText Transfer Protocol)

 

[index]

1. HTTP란 무엇일까?

    1-1. HTTP의 개념

    1-2. HTTP 특징 4가지

    1-3. HTTP로 제어할 수 있는 것

    1-4. HTTP 저번에 따른 사항들

 

2. HTTP 요청과 응답

    2-1. HTTP 서버 구조

    2-2. HTTP 요청에 포함되는 요소

    3-3. HTTP 응답에 포함되는 요소

 

3. HTTP 통신 흐름

 

4. HTTP 보안 취약점과 해결 방안

    4-1. HTTP 보안 취약점

    4-2. HTTP 보안 취약 문제 해결 방안

 

---

 

1. HTTP란 무엇일까?

1-1. HTTP의 개념

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

HTTP는 네트워크 장치 간에 정보를 전송하도록 설계된 애플리케이션 계층 프로토콜이며 네트워크 프로토콜 스택의 다른 계층 위에서 실행됩니다. 또한 HTTP는 애플리케이션 계층의 최상위에 있습니다.

HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 

 

HTTP는 사용이 쉬운 확장 가능한 프로토콜입니다. 헤더를 쉽게 추가하는 능력을 지닌 클라이언트-서버 구조는 HTTP가 웹의 확장된 수용력과 함께 발전할 수 있게 합니다.

 

 1-2. HTTP의 특징 4가지

① 간결함

HTTP는 사람이 읽을 수 있으며 간단하게 고안되었습니다. 심지어 HTTP/2가 다소 더 복잡해졌지만 여전히 HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지하였습니다. HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 초심자의 진입장벽을 낮췄습니다.

 

② 확장 가능성

HTTP/1.0에서 소개된, HTTP 헤더는 HTTP를 확장하고 실험하기 쉽게 만들어주었습니다. 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있습니다.

 

③ Stateless & Session

HTTP는 상태를 저장하지 않습니다(Stateless).

동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없습니다. 이는 e-커머스 쇼핑 바구니처럼, 일관된 방식으로 사용자가 페이지와 상호작용하길 원할 때 문제가 됩니다.

하지만, HTTP의 핵심은 상태가 없는 것이지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다. 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가됩니다.

 

④ HTTP와 연결

트랜잭션 중심의 비연결성 프로토콜

종단간 연결이 없습니다. 연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖입니다. HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않습니다. 다만 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구할 뿐입니다. 인터넷 상의 가장 일반적인 두 개의 전송 프로토콜 중에서 TCP는 신뢰할 수 있으며 UDP는 그렇지 않습니다. 그러므로 HTTP는 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존합니다.

클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 합니다. HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 여는 것입니다. 이 동작은 여러 요청을 연속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 효율적이지 못합니다.

 

1-3. HTTP로 제어할 수 있는 것

1. 캐시
2. HTTP로 문서가 캐시되는 방식을 제어할 수 있습니다. 서버는 캐시 대상과 기간을 프로식와 클라이언트에 지시할 수 있습니다. 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에 지시할 수 있습니다.
3. ORIGIN 제약 사항을 완화
4. 스누핑과 다른 프라이버시 침해를 막기 위해 브라우저 사이트 간의 엄격한 분리를 강제하여 동일한 ORIGIN으로부터 온 페이지만 웹페이지의 전체 정보에 접근 할 수 있습니다. 이러한 제약 사항을 HTTP 헤더를 통해 완화시킬 수 있습니다. 다른 도메인으로부터 전달된 정보를 패치워크 할 수 있습니다.
5. 인증
6. 인증을 통해 특정 사용자만이 페이지에 접근 할 수 있도록 할 수 있습니다. 기본 인증은 HTTP를 통해 WWW-Authenticate 또는 유사한 헤더를 사용해 제공되거나 http 쿠키를 사용해 특정 세션을 설정하여 이룰 수 있습니다.
7. 프록시와 터널
8. Proxy servers and tunneling - HTTP | MDN
9. 세션
10. 쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. http가 기본적으로 상태가 없는 프로토콜임에도 세션을 만들어주는 계기가 됩니다.

 

1-4. HTTP 버전에 따른 사항들

3. HTTP의 표준 / 역사

  ※ ☞HTTP 버전 (HTTP 표준) 참조
     - HTTP 0.9 : 차후 정식 버전과 구분하기 위해 HTTP/0.9로 불리움 (1990년경)
     - HTTP 1.0 : 유용한 초기 개념들 도입 (1996년)
        .HTTP 헤더,HTTP 메서드,HTTP 응답 코드,리다이렉트, 비지속 연결(non-persistent) 등
     - HTTP 1.1 : HTTP 1.0 으로부터 기능 향상
        .RFC 2068 (1997년) =>RFC 2616 (1999년) =>RFC 7230~7235  (1998년~)
     - HTTP 2 : SPDY 기반 (2015)
     - HTTP 3 : HTTP 2 업그레이드 버전 (2020 ~)

1996~1997년에 출시된 최초의 HTTP 버전이 HTTP/1.1입니다. HTTP/2와 HTTP/3은 프로토콜 자체를 업그레이드한 버전입니다. 데이터 전송 시스템을 수정하면서 효율성을 개선했습니다.

 

HTTP/2는 텍스트 형식 대신, 바이너리로 데이터를 교환합니다. 또한, 서버가 새 HTTP 요청을 기다리는 대신, 클라이언트 캐시에 응답을 사전에 전송할 수 있습니다. HTTP/2가 성능 향상을 위해 HTTP 메시지를 프레임 내로 임베드하여 약간의 복잡함을 더했을지라도, 애플리케이션의 관점에서 볼 때, 메시지의 기본적인 구조는 HTTP/1.0이 릴리즈된 이후와 동일합니다. 세션의 흐름은 여전히 단순하여, 간단한 HTTP 메시지 모니터를 이용한 조사와 디버그를 가능하게 해줍니다.

 

HTTP/3은 비교적 최근에 나온 버전이며, HTTP/2를 한 단계 더 발전시킨 것입니다. HTTP/3의 목표는 실시간 스트리밍 및 기타 최신 데이터 전송 요구 사항을 보다 효율적으로 지원하는 것입니다.

 

---

2. HTTP  요청과 응답

2-1. HTTP 클라이언트-서버 구조 

HTTP는 클라이언트-서버 프로토콜입니다.

클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부릅니다.

요청은 하나의 객체, 사용자 에이전트에 의해 전송됩니다. 대부분의 경우, 사용자 에이전트는 브라우저이지만 다른 것도 가능합니다.

이 요청과 응답 사이에는 여러 개체들이 존재합니다, 예로 들면, 다양한 작업을 수행하는 게이트웨이와 캐시 역할을 하는 프록시 등이 있습니다.

 

프록시

웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메세지를 이어 받고 전달합니다. 애플리케이션 계층에서 동작하는 것을 일반적으로 프록시라고 부릅니다. 클라이언트와 서버 사이에 위치하며 중개자 역할을 합니다.

동일 프로토콜 내에서 연결 

 

수행하는 기능들

• 캐싱 : 브라우저 캐시 (공개 또는 비공개)
• 필터링 : 바이러스 백식 스캔, 유해 컨텐츠 차단
• 로드 밸런싱 : 여러 서버들이 서로 다른 요청을 처리하도록 허용
• 인증 : 다양한 리소스에 대한 접근 제어
• 로깅 : 이력 정보를 저장

 

게이트 웨이

• 프록시처럼 중계 역할을 하나, HTTP 프로토콜 이외 기능을 수행 ⇒ 프로토콜 변환
• 서로 다른 프로토콜 간을 변환해주며 연결

 

2-2. HTTP 요청에 포함되는 요소

1. HTTP 버전 유형
2. URL
3. HTTP 메서드
4. HTTP 요청 헤더
5. HTTP 본문 (선택 사항)

 

HTTP METHOD 

HTTP 요청이 쿼리된 서버에서 기대하는 작업을 나타냅니다.

[ CRUD 관점에서 설명해야함 ] Create(생성), Read(읽기), Update(갱신), Delete(삭제)

• POST : 서버나 특정 리소스에 엔티티를 제출할 때 사용합니다. Create나 Update, Delete등을 할 때 사용하기도 합니다. [Create]
• GET : 특정 리소스의 참조를 요청합니다. CRUD를 예로 들 경우 R에 해당합니다. url에 어느 리소스를 참조 요청하는지 드러나게 됩니다.[Read]
• PUT: PUT를 통해 해당 리소스를 수정합니다. UPDATE를 하지만 전체 자원을 업데이트 하는데 쓰인다고 합니다. [Update]
• DELETE : 삭제 할 때 사용. 어느 자원을 삭제할 지 url에 드러나게 됩니다.[Delete]
• PATCH: 리소스의 부분을 수정하는데 사용합니다. 의미론적으로 UPDATE와 더 가깝다고 할 수 있습니다.

HTTP Request Method GET : 특정 리소스의 참조를 요청합니다. CRUD를 예로 들 경우 R에 해당합니다. url에 어느 리소스를 참조 요청하는지 드러나게 됩니다. POST: 서버나 특정 리소스에 엔티티를 제출할 때 사용합니다. Create나 Update, Delete등을 할 때 사용하기도 합니다. PUT: UPDATE를 하지만 전체 자원을 업데이트 하는데 쓰인다고 합니다. DELETE: 삭제 할 때 사용. 어느 자원을 삭제할 지 url에 드러나게 됩니다. PATCH: 리소스의 부분을 수정하는데 사용합니다. 의미론적으로 UPDATE와 더 가깝다고 할 수 있습니다.

 

HTTP 요청 헤더

HTTP 요청 헤더에는 키-값 쌍에 저장된 텍스트 정보가 포함되어 있으며 헤더는 모든 HTTP 요청에 포함됩니다. 이러한 헤더는 클라이언트가 사용하는 브라우저 및 요청되는 데이터와 같은 핵심 정보를 전달합니다.

 

 HTTP 요청 본문

요청 본문에는 요청에서 전송되는 정보의 ‘본문’을 포함하는 부분입니다. 사용자의 이름 및 비밀번호 또는 양식에 입력된 기타 데이터와 같이 웹 서버에 제출되는 모든 정보가 포함됩니다.

 

 

2-3. HTTP 응답에 포함되는 요소

1. HTTP 상태 코드
2. HTTP 응답 헤더
3. HTTP 본문( 선택 사항)

 

HTTP 상태 코드

클라이언트(사용자)가 웹 서버에 HTTP 요청을 했을 때 웹 서버는 응답으로 HTTP 상태 코드를 알려주게 됩니다.

이러한 코드는 HTTP 요청의 성공/실패 여부를 알려주는 코드이며 5개의 그룹으로 나눠집니다.

HTTP Status Code 분류 (XX : 00~99)

• 1xx (조건부 응답) ⇒ 현재 요청을 받았으며, 직접 진행 중
• 2xx (성공) ⇒ 현재 서버가 클라이언트의 요청을 받았으며, 성공적으로 처리했음
• 3xx (리다이렉션 완료) ⇒ 클라이언트가 요청을 완료하기 위해 리다이렉션이 이루어져야함
• 4xx (클라이언트 요청 오류) ⇒ 클라이언트의 요청 오류
• 5xx (서버 오류) ⇒ 올바른 클라이언트 요청에 서버가 응답할 수 없음

클라이언트가 웹 페이지를 요청한 후 가장 일반적으로 표시되는 응답의 상태 코드는 200 OK

URL에 오타가 있거나 할 때 404 NOT FOUND 상태 코드가 발생

잘못된 요청일 때 400 - Bad request

 

HTTP 응답 헤더

HTTP 응답에는 응답 본문에서 전송되는 데이터의 언어 및 형식과 같은 중요한 정보를 전달하는 헤더가 함께 제공됩니다.

 

HTTP 응답 본문

GET 요청에 대한 성공적인 HTTP 응답에는 일반적으로 요청된 정보가 포함된 본문이 있습니다. 대부분의 웹 요청의 경우 이는 웹 브라우저에서 웹 페이지로 변환되는 HTML 데이터입니다.

 

---

3. HTTP 통신 흐름

1. TCP 연결
2. TCP 연결은 요청을 보내거나 응답을 받는데 사용됩니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있습니다.
3. HTTP 메세지를 전송 
4. GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
5. HTTP 메세지는 HTTP/2 이전 까지는 인간이 읽을 수 있었습니다. 이후로는 간단한 메세지가 프레임 속으로 캡슐화되어 직접 읽는 것은 불가능해졌습니다.
6. 서버에 의해 전송된 응답 읽기
7. HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
8. 연결을 닫거나 다른 요청을 위해 재사용
9. HTTP 파이프 라이닝이 활성화되면 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. HTTP 파이프 라이닝은 오래된 소프트웨어와 최신 버전이 공존하고 있는, 기존의 네트워크 상에서 구현하기 어렵다는게 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있습니다.

 

---

4. HTTP 보완 취약점과 해결 방안

4-1. HTTP 보안 취약점

1. 도청이 가능하다
   • 평문으로 통신하기 때문에 도청이 가능하다
   • 이를 해결하기 위해서 통신자체를암호화(HTTPS)하거나 데이터를 암호화 하는 방법등이 있다
   • 데이터를 암호화 하는 경우 수신측에서는 보호화 과정이 필요하다
2. 위장이 가능하다
   • 통신 상대를 확인하지 않기 깨문에 위장된 상대와 통신할 수 있다
   • HTTPS는 CA 인증서를 통해 인증된 상대와 통신이 가능하다
3. 변조가 가능하다
   • 완전성을 보장하지 않기 때문에 변조가 가능하다
   • HTTPS는 메세지 인증 코드(MAC), 전자 서명등을 통해 변조를 방지 한다

 

4-2. HTTP 보안 취약 문제 해결 방안

HTTP/1.1

이러한 결함을 개선하기 위해, HTTP/1.1은 (구현하기 어렵다고 입증된) 파이프라이닝 개념과 지속적인 연결의 개념을 도입했습니다: 기본적인 TCP 연결은 [Connection](<https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Connection>) 헤더를 사용해 부분적으로 제어할 수 있습니다.

Connection당 하나의 요청을 처리 하도록 설계 되어 있다. 그래서 동시전송이 불가능하고 요청과 응답이 순차적으로 이루어 지게된다. 그렇다 보니 HTTP문서안에 포함된 다수의 리소스 (CSS, JS, Images)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기 시간)는 길어지게 된다.

HTTP/1.1 단점

• HOL(Head Of Line) Blocking – 특정 응답의 지연
• RTT(Round Trip Time) 증가
• 무거운 Header 구조 (특히 Cookie)

 

HTTP/2

HTTP/2는 연결을 좀 더 지속되고 효율적으로 유지하는데 도움이 되도록, 단일 연결 상에서 메시지를 다중 전송(multiplex)하여 한 걸음 더 나아갔습니다.

HTTP/2.0 장점

• Multiplexed Streams
  • 한 커넥션으로 동시에 여러개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받는다. HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선이라 보면 된다.
• Stream Prioritization
• 예를 들면 클라이언트가 요청한 HTML문서안에 CSS파일 1개와 Image파일 2개가 존재하고 이를 클라이언트가 각각 요청하고 난 후 Image파일보다 CSS파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생한다. HTTP/2의 경우 리소스간 의존관계(우선순위)를 설정하여 이런 문제를 해결하고 있다.
• Server Push
  • 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 마음대로 보내줄 수 도 있다.
  • 클라이언트가 HTML문서를 요청했고 해당 HTML에 여러개의 리소스(CSS, Image…) 가 포함되어 있는경우 HTTP/1.1에서 클라이언트는 요청한 HTML문서를 수신한 후 HTML문서를 해석하면서 필요한 리소스를 재 요청한다.
  • HTTP/2에선 Server Push를 이용하면 클라이언트가 요청하지도 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상을 이끌어 낸다.
  • 이를 PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 하지 않는다.

 

그리고 HTTP의 보안 문제들을 해결 하기 위해 나온 것이 바로 HTTPS입니다.

HTTPS에 대한 자세한 설명은 아래의 링트를 참고해주세요.

 HTTPS에 대한 글 보러가기

---

참고 자료

HTTP 개요 - HTTP | MDN

HTTP 개요 - HTTP | MDN

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/HTTP%20%26%20HTTPS.md

[Network] HTTP 상태 코드

[Network] HTTP 상태 코드

HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS

HTTP와 HTTPS 비교 - 전송 프로토콜 간의 차이점 - AWS