http vs https

http(Hyper Text Transfer Protocol)에 대하여

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

HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면, 서버가 응답하는 것입니다.
웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킵니다.
이 포트는 일반적으로 TCP/80 또는 TCP/8080입니다.

 

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

리눅스 포트 정리

자세한 포트의 내용은 위 링크에서 아래 이미지는 형식입니다!

---

HTTP 메시지

HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답합니다
기능과 세부 구조에서는 차이가 있지만, 크게 보면 이들은 HTTP 헤드와 바디로 구성된다는 공통점있죠

---

HTTP 헤드

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

 

시작 줄의 역할은 요청과 응답에서 큰 차이가 있습니다.
그러므로 이에 대해서는 조금 뒤에 각각을 자세히 기술하면서 설명하겠습니다.

 

해더 - 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성
하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있습니다.

---

HTTP 바디

HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말합니다.
클라이언트나 서버에게 전송하려는 데이터가 바디에 담깁니다

---

HTTP 요청

HTTP 요청은 서버에게 특정 동작을 요구하는 메시지입니다.

 

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

---

시작 줄

HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성
각각은 띄어쓰기로 구분합니다.

 

메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타냅니다.
HTTP 표준에 정의된 메소드는 8개가 있으나, 여기서는 비교적 자주 사용되는 GET과 POST 메소드만..

먼저 GET은 리소스를 가져오라는 메소드입니다. 이용자가 브라우저에 웹 서버의 주소를 입력하거나
하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요합니다.
이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아옵니다.

반대로, POST는 리소스로 데이터를 보내라는 메소드입니다. 전송할 데이터는 보통 HTTP 바디에 포함함
예시로 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보냄

 

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

---

헤더와 바디

시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같습니다.

 

📎HTTP 요청의 메소드 및 URI에 대해 더 자세히 알고 싶다면, 표준 문서를 보실 것을 추천합니다

HTTP/1.1: Request

---

HTTP 응답

HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지입니다.
요청을 수행 여부 그리고 이유와 같은 상태 정보(Status), 클라이언트에 전송할 리소스가 응답에 포함.

---

시작 줄

HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성!
각각은 띄어쓰기로 구분됩니다.

 

HTTP 버전은 서버에서 사용하는 HTTP 프로토콜의 버전을 나타냅니다.
그리고 상태 코드는 요청에 대한 처리 결과를 세 자릿수로 나타냅니다.

 

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

처리 사유는 상태 코드가 발생한 이유를 짧게 기술한 것입니다.

상태	코드 설명	대표 예시
1xx	요청을 제대로 받았고, 처리가 진행 중임
2xx	요청이 제대로 처리됨	200: 성공
3xx	요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함.	302: 다른 URL로 갈 것
4xx	클라이언트가 잘못된 요청을 보내어 처리에 실패했습니다.	400: 요청이 문법에 맞지 않음 403: 클라이언트가 리소스에 요청할 권한 X 404: 리소스가 없음
5xx	클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패했습니다.	500: 요청을 처리하다가 에러가 발생함   503: 서버가 과부하로 인해 요청을 처리 X

---

헤더와 바디

시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같습니다.

📎HTTP 응답에 대해 더 자세히 알고 싶다면, 표준 문서를 보실 것을 추천!

HTTP/1.1: Response

---

https

HTTP의 응답과 요청은 평문으로 전달됩니다. 이는 심각한 보안 문제로 이어지죠
예를 들어, 로그인할 때 전송한 POST 요청에는 대개 이용자의 ID와 비밀번호가 포함됩니다.
공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있습니다.

HTTPS(HTTP over Secure socket layer)는 TLS(Transport Layer Security) 프로토콜을 도입

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

왼쪽은 http 오른쪽은 https

위에 사진은 HTTP 및 HTTPS의 웹 서버와 오가는 메시지를 Wireshark로 확인한 것입니다.
빨간 글자는 요청, 파란 글자는 응답이고 HTTP 메시지는 쉽게 읽을 수 있지만, HTTPS의 것은 해석불가

 

웹 서버의 URL이 http://로 시작되면 HTTP, https://로 시작되면 HTTPS 프로토콜을 사용합니다. 
그리고 요즘은 다 HTTPS를 지향하는 편이죠

TLS 표준

 TLS의 기반이 되는 공개 키 암호 시스템(Public Key Crypto Standard, PKCS) 및 대칭 키 암호(Symmetric Key Cryptography)을 알아야하며, 아례 문서를 읽으면 이해에 도움될 겁니다 암호학 기초도 배우시고..

RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2

 

---

정리

• HTTP(HyperText Transfer Protocol): 웹 서버와 client가 리소스를 교환에 사용하는 프로토콜.
  클라이언트가 요청하면, 서버가 응답하는 방식.
• HTTP 메시지: HTTP 서버와 client가 교환하는 데이터. 헤드와 바디로 구성되며, 각 줄은 CRLF로 구분됨.
  • 헤드: 메시지에 대한 정보. 헤드의 끝에는 CRLF*가 한 줄 있음.
  • 바디: 클라이언트가 서버에게, 또는 서버가 클라이언트에게 전달할 데이터
  • *CRLF(줄바꿈), EOL(end-of-line) 등으로 지칭하며 통용됨
• HTTP 요청(Request): 클라이언트가 서버에게 특정 동작을 요청하는 메시지
  • 메소드(Method): 요청 URI가 가리키는 리소스에 대해, 서버가 수행했으면 하는 동작을 지정
  • 요청 URI(Request-URI): 메소드의 대상이 되는 리소스를 지정
• HTTP 응답(Response): 요청을 처리한 결과 및 이유, 클라이언트에 전송 웹 리소스를 포함한 메시지
  • 상태 코드(Status Code): 요청을 처리한 결과
  • 처리 사유(Reason Phrase): 상태 코드가 발생한 이유
• HTTPS(HTTP on Secure socket layer): TLS를 이용하여 HTTP의 약점을 보완한 프로토콜

•  

---

참고 자료

Background: HTTP/HTTPS

HTTP/HTTPS Analysis Using Wireshark

 

참고 이미지