카테고리 없음

HTTP/HTTPS

KIKI_BI0 2024. 1. 9. 23:45
SMALL

HTTP

HTTP(Hyper Text Transfer Protocol)

: 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response)형식으로 정의한 프로토콜

기본 매커니즘 : 클라이언트가 서버에게 요청하면, 서버가 응답하는 것

웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다.

이 포트는 일반적으로 TCP/80 또는 TCP/8080이다.

클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석해 적절한 응답을 반환한다.

ex)

Request

""" HTTP Method """
GET  

""" Request URI """
/index.html

""" HTTP Version """
HTTP/1.1

""" Request Header """
Host: dreamhack.io
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36

Response

""" HTTP Version """
HTTP/1.1

""" Return Code """
200 OK

""" Response Header """
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 61
Connection: Keep-Alive
Content-Type: text/html

""" Response Body """
<!doctype html>
<html>
<head>
</head>
<body>
</body>
</html>
  • +) 네트워크 포트와 서비스 포트네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소를 의미클라이언트가 서버의 포트에 접근해 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보낸다고 생각하기서비스 포트(Service Port)ex) HTTP가 80번 포트를 점유하고 있다면, HTTP의 서비스 포트는 80번 포트가 된다.대표적으로 TCP와 UDP가 있다.그래서 서비스 포트를 표기할 때는 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 한다.포트의 개수는 운영체제에서 정의하기 나름이다.포트 중 0번부터 1023번 포트는 잘 알려진 포트(Well-known port) 또는 특권 포트(Privileged port)라고 한다. → 각 포트 번호에 유명한 서비스가 등록되어있음잘 알려진 포트에 서비스를 실행하려면 관리자 권한이 필요하다. 따라서 클라이언트는 이대역에서 실행 중인 서비스들은 관리자의 것이라고 신뢰할 수 있다.
  • 대표적으로, 22번 포트에는 SSH, 80에는 HTTP, 443에는 HTTPS가 할당되어 있다.
  • 그러나 현대의 윈도우, 리눅스, 맥 운영체제는 0번부터 65535번까지, 총 65535개의 같은 수의 네트워크 포트를 사용한다.
  • ex) HTTP의 서비스 포트가 TCP/80 이라고 하면, HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 뜻이다.
  • → TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 않는다. 반대도 마찬가지
  • 포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따른다.
  • 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트
  • 네트워크 포트를 줄여서 그냥 포트라고 부르기도 함
  • <포트의 기능 이해하기>
  • 네트워크 포트(Network Port)

HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있다.

HTTP 헤드

HTTP 헤드의 각 줄은 CRLF로 구분되며, 첫 줄은 시작 줄(Start-line), 나머지 줄은 헤더(Header)라고 부른다. 헤드의 끝은 CRLF 한 줄로 나타낸다.

헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 버디의 속성을 나타낸다.

하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있다.

HTTP 바디

HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말한다.

클라이언트나 서버에게 전송하려는 데이터가 바디에 담긴다.

  • +) CRLF?Carriage Return은 커서를 현재 줄의 맨 앞으로 이동시키는 문자이고, Line Feed는 커서를 다음 줄로 이동시키는 문자이다.윈도우 운영체제에서는 줄을 종결하기 위해 CRLF를 사용하고, 리눅스도 같이 유닉스 기반 운영체제에서는 LF만을 사용한다.
  • 주로 텍스트 파일에서 줄 바꿈을 나타내는 데 사용되는 제어 문자열
  • Carriage Return(CR)와 Line Feed(LF)의 조합을 나타낸다.

HTTP 요청

서버에게 특정 동작을 요구하는 메시지

서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고, 적절할 때만 이를 처리

→ 시작 줄

HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성됨

각각 띄어쓰기로 구분

Method

URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타냄

HTTP 표준에 정의된 메소드는 8개

<Method 일부>

  1. GET이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요함 → 이때 브라우저는 GET 요청을 서버에 전송해 리소스를 받아옴
  2. 리소스를 가져오라는 메소드
  3. POST전송할 데이터는 보통 HTTP 바디에 포함됨
  4. 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내짐
  5. 리소스로 데이터를 보내라는 메소드

이 외에 요청 URI는 메소드의 대상, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타냄

GET 요청 구조

POST 요청 구조

HTTP 응답

HTTP 요청에 대한 결과를 반환하는 메시지

요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함됨

→ 시작 줄

HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Response Phrase)로 구성됨

각각은 띄어쓰기로 구분

HTTP 버전

서버에서 사용하는 HTTP 프로토콜의 버전을 나타냄

상태 코드

요청에 대한 처리 결과를 세 자릿수로 나타냄

HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데, 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류됨

처리 사유

상태 코드가 발생한 이유를 짧게 기술한 것

| 상태

코드 설명 대표 예시

1xx 요청을 제대로 받았고, 처리가 진행 중임  
2xx 요청이 제대로 처리됨 → 200(OK) : 성공
3xx 요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함 → 302(Found) : 다른 URL로 갈 것
4xx 클라이언트가 잘못된 요청을 보내어 처리에 실패함 → 400(Bad Request) : 요청이 문법에 맞지 않음

→ 401(Unauthorized) : 클라이언트가 요청한 리소스에 대한 인증이 실패함

→ 403(Forbidden) : 클라이언트가 리소스에 요청할 권한이 없음

→ 404(Not Found) : 리소스가 없음 | | 5xx | 클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패함 | → 500(Internal Server Error) : 서버가 요청을 처리하다가 에러가 발생함

→ 503(Service Unavailable) : 서버가 과부하로 인해 요청을 처리할 수 없 |

200 상태코드를 갖는 응답

HTTP Request & Response

원하는 메소드를 선택해 요청을 전송하면, 그림과 같이 전송된 요청 및 응답의 구조를 확인할 수 있음

HTTPS

**HTTPS(HTTP over Secure socket layer)**는 TLS(Transport Layer Security) 프로토콜을 도입해 HTTP의 문제점을 보완함

TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화함 → 공격자가 충간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능함 → 결과적으로 HTTP 통신이 도청과 변조로부터 보호됨

밑의 사진은 HTTP 및 HTTPS의 웹 서버와 오가는 메시지를 Wireshark로 확인한 것

빨간 글자는 요청, 파란 글자는 응답

HTTP 메시지는 쉽게 읽을 수 있지만, HTTPS의 것은 해석할 수 없음

 

LIST