What is HTTP?

Notion : https://denim-shrew-8cb.notion.site/Internet-c51e3bd0898b47d09ab2c944512faa63

HTTP란?

HTTP(Hypertext Transfer Protocol)는 웹 페이지와 그와 관련된 자원(이미지, 비디오, 스크립트 등)을 인터넷을 통해 전송하기 위한 프로토콜이다.

HTTP는 클라이언트와 서버가 서로 통신하는 방법을 표준화하는 TCP/IP 기반 응용 계층 통신 프로토콜로 고전적인 “클라이언트-서버 모델”을 따른다.

HTTP는 상태 비저장 프로토콜이며, 이는 서버가 두 요청 사이에 데이터(상태)를 유지하지 않음을 의미한다. 웹에서의 주요 통신 방식으로 사용되며, 웹 서버와 웹 브라우저 간의 통신에 사용된다.

 

HTTP 동작 방식

1. 사용자가 웹 브라우저를 통해 웹 사이트에 접속하면, 브라우저는 웹 서버에 HTTP요청을 전송한다. 이 요청은 웹 페이지의 HTML, CSS, JavaScript 등을 서버에 요청하는 것을 포함할 수 있다.
2. 웹 서버는 요청을 받아 적절한 응답을 생성하고, 이 응답을 웹 브라우저로 되돌려 보낸다. 응답은 보통 웹 페이지의 내용이나 에러 메시지가 포함되어 있다.
3. 웹 브라우저는 서버로부터 받은 응답을 처리해 웹 페이지를 렌더링하고 사용자에게 표시한다.

 

HTTP 요청(Request)

HTTP 요청은 웹 클라이언트가 웹 서버에 정보를 요청하거나 데이터를 전송할 때 사용하는 메시지이다. HTTP 요청에는 다음과 같은 구성 요소들이 포함된다

1. 요청 메서드(Request Method)
   웹 서버에 수행할 작업을 지시하는 동작(예: GET, POST, PUT, DELETE 등).
2. 요청 URI(Request URI)
   요청 대상 리소스의 위치를 식별하는 URL(Uniform Resource Locator) 또는 URI(Uniform Resource Identifier).
3. HTTP 버전(HTTP Version)
   요청이 사용하는 HTTP 프로토콜의 버전(예: HTTP/1.1, HTTP/2, HTTP/3).
4. 헤더(Headers)
   요청에 대한 추가 정보를 제공하는 key-value 쌍. 일반적인 헤더에는 Host, User-Agent, Content-Type, Content-Length, Accept, Authorization 등이 있다.
5. 요청 본문(Request Body)
   클라이언트가 서버에 데이터를 보낼 때 사용되는 부분으로, 주로 POST, PUT, PATCH와 같은 메서드에서 사용된다. 요청 본문은 서버에 전달할 데이터를 포함하며, 헤더의 Content-Type 및 Content-Length 속성에 따라 다양한 형식(JSON, XML, 폼 데이터 등)으로 인코딩된다.

HTTP request example

POST /api/users HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: application/json
Content-Type: application/json
Content-Length: 52
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

{
  "username": "johndoe",
  "email": "john@example.com",
  "age": 30
}

 

HTTP Method

주요 HTTP 매서드는 다음과 같다

1. GET
   서버에서 특정 리소스를 요청한다. GET 요청은 데이터를 검색하기 위한 것이므로 서버의 데이터를 변경하지 않는다. 예를 들어, 브라우저에서 웹 페이지를 열 때 주로 GET 요청을 사용한다.
2. POST
   서버에 새로운 리소스를 생성하거나 기존 리소스를 수정할 때 사용한다. 예를 들어, 웹 폼을 작성하여 서버에 데이터를 전송할 때 POST 요청을 사용한다.
3. PUT
   서버의 특정 리소스를 완전히 대체하거나 새로운 리소스를 생성할 때 사용한다. PUT 요청은 idempotent하므로 여러 번 호출되어도 동일한 결과를 생성한다.
4. DELETE
   서버에서 특정 리소스를 삭제할 때 사용한다.
5. PATCH
   서버의 리소스를 부분적으로 수정할 때 사용한다. 수정할 내용만 전달되어야 한다.

이 외에도 OPTIONS, HEAD, CONNECT 등의 메서드가 있지만, 일반적인 웹 애플리케이션에서는 상기 메서드들이 주로 사용된다.

 

HTTP 버전 및 특징

1. HTTP/1.0
   1996년에 처음 발표된 이 버전은 웹이 초기에 사용한 기본 프로토콜이다. HTTP/1.0에서 각 요청마다 새로운 TCP 연결이 필요했기 때문에 비효율적이었다.
2. HTTP/1.1
   1997년에 처음 발표되었으며, 그 이후 몇 차례의 개정이 있었다. HTTP/1.1은 **지속적인 연결(persistent connections)**과 파이프라이닝(pipelining) 기능을 도입해 효율성과 성능을 개선하였다. 현재 웹에서 가장 많이 사용되는 HTTP 버전이다.
3. HTTP/2
   2015년에 발표되어 HTTP/1.1의 성능 문제를 개선하기 위해 설계된 최신 버전이다. HTTP/2는 헤더 압축, 다중화, 서버 푸시 등의 기능을 통해 웹 페이지 로딩 속도를 높이고 효율성을 개선하였다.
4. HTTP/3
   2020년에 IETF(Internet Engineering Task Force)에 의해 공식적으로 채택된 버전이다. HTTP/3의 핵심 차이점은 기존의 TCP(Transmission Control Protocol) 대신 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다는 것이다. QUIC는 구글이 개발한 프로토콜로, UDP(User Datagram Protocol)를 기반으로 하여 낮은 지연시간과 높은 성능을 제공한다.
   HTTP/3를 사용하면 다음과 같은 이점이 있습니다
   1. 연결 설정 지연 시간 감소
      QUIC은 TCP 대비 더 빠른 연결 설정을 가능하게 한다.
   2. 헤드 오브 라인 블로킹(HOL blocking) 문제 해결
      QUIC은 독립적인 스트림으로 데이터를 전송하기 때문에, 하나의 스트림에서 발생한 지연이 다른 스트림에 영향을 주지 않는다.
   3. 연결 이동성(Connection mobility)
      QUIC은 IP 주소가 변경되더라도 연결을 유지할 수 있어 모바일 기기에서의 웹 사용에 이점이 있다.
   4. 내장형 암호화QUIC은 기본적으로 암호화를 지원하므로 보안성이 개선된다.
   하지만 아직 초기 단계에 있으며 점차 많은 웹 사이트와 브라우저에서 지원될 것으로 기대된다.

 

HTTP 요청 헤더(request headers)

HTTP 헤더는 key-value 쌍에 저장된 텍스트 정보를 포함하며, 모든 HTTP 요청(및 응답, 나중에 더 자세히)에 포함된다.

이러한 헤더는 클라이언트에서 사용 중인 브라우저와 요청 중인 데이터와 같은 핵심 정보를 전달한다.

• Host: 요청이 전송되는 서버의 도메인 이름
• User-Agent: 클라이언트(브라우저)의 정보를 나타내는 문자열
• Accept: 클라이언트가 수용할 수 있는 응답의 MIME 타입

💡 MIME(Multipurpose Internet Mail Extensions) 타입은 전자 메일을 위해 처음 개발되었으나, 이후 웹에서도 널리 사용되게 되었다. MIME 타입은 데이터의 형식을 나타내는 두 부분으로 구성된 문자열이다: 첫 번째 부분은 데이터의 주요 유형을 나타내며, 두 번째 부분은 구체적인 서브타입을 나타낸다. 이 두 부분은 슬래시(/)로 구분된다.
예: text/html: HTML 문서, application/json: JSON 형식의 데이터

• Content-Type: 요청 본문의 데이터 형식 (예: JSON, XML 등)
• Content-Length: 요청 본문의 길이(바이트 단위)
• Authorization: 클라이언트의 인증 정보 (예: Bearer 토큰, 기본 인증 등)

HTTP 헤더의 Accept 필드는 클라이언트가 서버로부터 받아들일 수 있는 MIME 타입을 나열한다. 이는 서버가 클라이언트가 이해할 수 있는 형식의 데이터를 제공할 수 있도록 도움을 준다. 클라이언트는 여러 MIME 타입을 쉼표로 구분하여 나열할 수 있으며, 각 MIME 타입에 대해 선호도를 나타내는 가중치(q) 값을 지정할 수도 있다.

예를 들어, 클라이언트가 JSON과 XML 형식의 데이터를 모두 받아들일 수 있지만, JSON을 선호한다고 가정해 봅시다. 이 경우 Accept 헤더는 다음과 같이 설정될 수 있다:

Accept: application/json;q=0.9, application/xml;q=0.8

이 예시에서는 JSON의 선호도(q) 값이 0.9, XML의 선호도 값이 0.8로 설정되어 있으므로, 서버는 가능한 JSON 형식의 데이터를 우선적으로 제공할 것이다.

 

HTTP 요청 본문(request body)

위에 예시를 보면 JSON형식의 데이터가 요청 본문에 포함되어 있다.

{
  "username": "johndoe",
  "email": "john@example.com",
  "age": 30
}

요청 본문에는 클라이언트가 서버에 전송하려는 데이터가 포함되며, 본문의 형식은 Content-Type 헤더에 명시된 것에 따라 다르다. 이 예시에서는 JSON 형식을 사용했지만, 다른 경우에는 폼 데이터, XML 등 다양한 형식을 사용할 수 있다.

 

HTTP 응답(response)

HTTP 응답(response)은 웹 서버가 클라이언트의 요청(request)에 대한 결과를 반환하는 메시지이다.

HTTP 응답에는 다음과 같은 구성 요소들이 포함되어 있다:

1. 상태 코드(Status Code)
   요청의 성공, 실패 또는 에러 상태를 나타내는 세 자리 숫자(예: 200 OK, 404 Not Found, 500 Internal Server Error 등).
2. HTTP 버전(HTTP Version)
   응답이 사용하는 HTTP 프로토콜의 버전(예: HTTP/1.1, HTTP/2, HTTP/3).
3. 헤더(Headers)응답에 대한 추가 정보를 제공하는 key-value 쌍. 일반적인 헤더에는 Content-Type, Content-Length, Server, Date, Set-Cookie 등이 있다.
4. 응답 본문(Response Body)
   서버가 클라이언트에 반환하는 데이터로, HTML, JSON, XML, 이미지, 오디오, 비디오 등 다양한 형식으로 제공될 수 있다. 헤더의 Content-Type 및 Content-Length 속성에 따라 본문의 형식과 크기가 결정된다.

HTTP 응답 예시

HTTP/1.1 200 OK
Date: Mon, 12 Sep 2022 18:30:00 GMT
Server: Apache/2.4.10 (Debian)
Content-Type: application/json
Content-Length: 50

{
  "userId": 1,
  "name": "John Doe",
  "email": "john@example.com"
}

 

 

HTTP 상태 코드(State Code)

HTTP 상태 코드는 서버가 클라이언트의 요청에 대해 응답하는 과정에서 요청 처리 결과를 나타내는 세 자리 숫자 코드이다.

 

상태 코드는 첫 번째 자리에 따라 다음과 같은 5개의 클래스로 구분된다

• 1xx (정보): 요청을 받았으며 프로세스를 계속 진행한다.
• 2xx (성공): 요청을 성공적으로 받았고, 이해했으며 수용했다.
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업이 필요하다.
• 4xx (클라이언트 에러): 요청 문법이 잘못되었거나 요청을 처리할 수 없다.
• 5xx (서버 에러): 서버가 명백히 유효한 요청에 대해 실패했다.

"xx"는 00과 99 사이의 다른 숫자를 나타낸다.

 

자주 사용되는 HTTP 상태 코드들은 다음과 같다

• 200 OK: 요청이 성공적으로 처리되었다.
• 201 Created: 요청이 성공적으로 처리되어 새로운 리소스가 생성되었다.
• 204 No Content: 요청이 성공적이지만 반환할 추가 데이터가 없다.
• 400 Bad Request: 클라이언트의 요청이 잘못된 구문이나 매개 변수로 인해 처리할 수 없다.
• 401 Unauthorized: 요청에 필요한 인증 정보가 없거나 잘못되었다.
• 403 Forbidden: 클라이언트는 요청한 리소스에 대한 권한이 없다.
• 404 Not Found: 요청한 리소스를 찾을 수 없다.
• 500 Internal Server Error: 서버 내부 에러로 인해 요청을 처리할 수 없다.
• 503 Service Unavailable: 서버가 일시적으로 서비스를 제공할 수 없다. 이는 일반적으로 과부하나 유지 보수로 인한 문제이다.

이 외에도 다양한 HTTP 상태 코드가 있으며, 각 코드는 특정한 상황을 나타낸다.

 

HTTP 응답 해더(response headers)

HTTP 응답 헤더는 서버가 클라이언트에 반환하는 응답 메시지의 일부로, 응답에 대한 부가 정보를 전달하는 key-value 쌍이다.

아래는 몇 가지 일반적인 HTTP 응답 헤더이다.

1. Content-Type
   응답 본문의 MIME 타입을 나타낸다. 예를 들어 HTML 문서는 'text/html', JSON 데이터는 'application/json' 등이 될 수 있다.
2. Content-Length
   응답 본문의 크기를 바이트 단위로 표시한다. 이 헤더는 클라이언트가 데이터를 올바르게 해석할 수 있도록 도와준다.
3. Date
   응답이 생성된 날짜와 시간을 나타낸다.
4. Server
   응답을 생성한 웹 서버의 정보를 나타낸다. 이 정보는 서버의 이름과 버전 등을 포함할 수 있다.
5. Set-Cookie
   클라이언트에 쿠키를 설정하거나 업데이트하는데 사용된다. 쿠키는 클라이언트의 상태 정보를 저장하고 서버에 전달하는 데 도움이 된다.
6. Cache-Control
   캐싱 동작을 제어하는 지시자를 나타낸다. 예를 들어 'no-cache', 'no-store', 'max-age' 등의 값이 사용될 수 있다.
7. Expires
   응답 데이터가 만료되는 날짜와 시간을 나타낸다. 이 헤더는 캐싱 동작을 제어하는 데 사용된다.
8. Last-Modified
   응답 데이터의 최종 수정 날짜와 시간을 나타낸다. 이 헤더는 캐싱과 조건부 요청을 처리하는 데 사용된다.
9. ETag
   응답 데이터의 버전을 나타내는 고유한 식별자이다. ETag는 캐싱과 조건부 요청을 처리하는 데 도움이 된다.
10. Access-Control-Allow-Origin
    CORS(Cross-Origin Resource Sharing)를 사용하여 리소스에 대한 권한 있는 출처를 나타낸다.

이 외에도 다양한 사용자 정의 헤더를 사용하여 추가 정보를 전달할 수 있다. 이러한 헤더는 'X-' 접두사로 시작하는 이름을 가질 수 있다(예: X-My-Custom-Header).

하지만, 'X-' 접두사는 현재 권장되지 않는 방식이다.

대신 사용자 정의 헤더를 사용할 때 적절한 이름을 지정하는 것이 좋다.

 

 

HTTP 응답 본문(response body)

HTTP 응답 본문(response body)은 웹 서버가 클라이언트에 반환하는 데이터를 포함한 부분이다.

본문의 데이터는 다양한 형식으로 제공될 수 있으며, 흔히 사용되는 데이터 형식은 다음과 같다:

1. HTML
   웹 페이지의 구조와 내용을 표현하는 하이퍼텍스트 마크업 언어이다. 웹 브라우저는 HTML을 구문 분석하여 사용자에게 시각적으로 표시한다.
2. JSON
   경량 데이터 교환 형식으로, key-value 쌍으로 구성된다. 웹 애플리케이션에서 클라이언트와 서버 간 데이터 전송에 주로 사용된다.
3. XML
   데이터를 구조화하고 설명하는 데 사용되는 마크업 언어이다. JSON과 유사한 목적으로 사용되지만, 좀 더 복잡한 문법을 가지고 있다.
4. 이미지, 오디오 및 비디오
   멀티미디어 콘텐츠를 클라이언트에 전달하는 데 사용된다. 각각의 형식은 해당 콘텐츠의 MIME 타입에 따라 결정된다(예: image/png, audio/mpeg, video/mp4).

응답 본문의 형식과 크기는 응답 헤더의 Content-Type 및 Content-Length 속성에 따라 결정된다.

일부 응답(예: 204 No Content 상태 코드)은 본문이 없을 수 있다. 이 경우, 서버는 요청 처리 결과에 대한 정보만 헤더를 통해 전달하고 별도의 데이터를 제공하지 않는다.

 

HTTP와 HTTPS의 차이점

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 기반한 보안 프로토콜로, 웹 서버와 브라우저 간에 암호화된 통신을 제공한다. 이로 인해 중간자 공격으로부터 데이터를 보호할 수 있으며, 사용자의 정보와 민감한 데이터가 안전하게 전송된다.

1. 보안
   보안은 이 둘의 가장 큰 차이점이다. HTTP는 평문(암호화되지 않은 데이터)으로 데이터를 전송하므로, 공격자가 데이터를 가로채거나 조작할 가능성이 있다. 반면에 HTTPS는 SSL/TLS라는 보안 프로토콜을 사용하여 데이터를 암호화한다. 이로 인해 중간자 공격(Man-in-the-Middle Attack)으로부터 보호받을 수 있으며, 사용자의 개인정보와 민감한 데이터가 안전하게 전송된다.
2. 포트 번호
   둘은 다른 프로토콜이므로 서로 다른 포트 번호를 사용한다. HTTP는 기본적으로 포트 80을 사용하며, HTTPS는 포트 443을 사용한다. 포트 번호는 웹 서버가 클라이언트 요청을 받기 위해 사용하는 통신 채널을 구분하는 식별자이다.
3. URL표시
   웹 브라우저의 주소 표시줄에서, HTTPS 사이트는 자물쇠 아이콘 또는 기타 보안 표시와 함께 **"https://"**로 시작하는 URL을 표시한다. 이는 사용자에게 해당 사이트가 안전하게 암호화되어 있음을 나타낸다. 반면 HTTP 사이트는 **"http://"**로 시작하는 URL을 사용하며, 대부분의 웹 브라우저에서 보안 경고를 표시합니다.
4. 인증서
   HTTPS를 사용하는 웹 사이트는 SSL/TLS 인증서를 필요로 합니다. 인증서는 웹 사이트의 신원을 확인하고, 서버와 클라이언트 간의 암호화된 연결을 설정하는데 사용된다. 인증서는 **신뢰할 수 있는 인증 기관(Certificate Authority, CA)**에 의해 발급되며, 웹 사이트가 안전하고 신뢰할 수 있는지 확인하는 역할을 한다. 대표적인 예로 Google Trust Services, Let's Encrypt가 있다. 이 둘은 구글에서 운영하는 CA이지만 영리와 비영리의 차이가 있다.
5. 검색 엔진 최적화(SEO)및 브라우저 경고
   HTTPS는 웹 사이트의 검색 엔진 최적화에 긍정적인 영향을 미친다. 구글 같은 검색 엔진들은 HTTPS를 사용하는 웹 사이트에 더 높은 순위를 부여하기 때문이다. 또한 대부분의 웹 브라우저는 HTTP 사이트에서 보안 경고를 표시하여 사용자에게 해당 사이트가 안전하지 않음을 알리기도 한다.
   

 

 

ref

• What is HTTP?
• How HTTPS Works …in a comic!
• An overview of HTTP
• Journey to HTTP/2
• HTTP/3 From A To Z: Core Concepts
• HTTP/3 Is Now a Standard: Why Use It and How to Get Started
• HTTP Crash Course & Exploration