HTTP
1. 정의
MDN Web Docs에 HTTP의 모든 것을 간결하게 요약한 정의가 있다.
Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes. HTTP follows a classical client-server model, with a client opening a connection to make a request, then waiting until it receives a response. HTTP is a stateless protocol, meaning that the server does not keep any data (state) between two requests. 출처: MDN Web Docs
HTTP는 응용계층(OSI 7계층과 관련된 내용으로, 이곳을 참조)에서 웹페이지 전송에 관한 규약이다. 웹 브라우저와 서버 간 통신을 위해 디자인되었지만 다른 목적으로도 사용될 수 있다. HTTP는 고전적인 클라이언트-서버 모델(클라이언트가 request하고 서버의 response를 기다리는)을 따른다. HTTP는 상태가 없는(state-less) 규약이므로, 서버는 두 request사이의 어떤 데이터(상태)도 저장하지 않는다.
2. HTTP의 두 가지 특징
2-1. Request/Response
한국어로는 요청/응답이다. 클라이언트는 서버에 요청하고, 서버는 요청에 대해 응답한다. 어느 하나만 있어서는 성립하지 않는다.
2-2. Stateless
상태가 없다? 단어만 봐서는 무슨 뜻인지 알기 어렵다. 하지만 전술했듯 상태를 '데이터'라고 생각하면 알기 쉬울 것 같다. 클라이언트가 서버에 요청을 보내고 또 다른 요청을 보내면 전에 보냈던 요청에 대한 데이터는 남아있지 않다. 그렇기 때문에 서버 디자인은 간결해 질 수 있는 반면, 응답할 때마다 보냈던 정보를 다시 보내야 한다는 단점이 존재한다.
3. Request, Response 구조
Request와 Response 모두 세 부분으로 구성되어 있다. Start line - Headers - Body
3-1. Request 구조
- Start Line: 클라이언트가 서버에게 일을 시작하도록 하는 메시지. HTTP 메소드, URL이나 절대경로로 구성된 타겟, HTTP 버전의 세 요소로 구성된다.
- Headers: 클라이언트의 요청에 관한 추가정보
- Body: 모든 요청에 body가 있는 것은 아니다. 서버에 데이터를 보내야 할 때 사용.
3-2. Response 구조
- Status Line: 응답에 관한 상태를 전달한다. HTTP버전, 상태 코드, 상태 메시지로 구성된다.
- Headers: 요청의 헤더와 동일하게 응답에 대한 추가정보를 포함한다.
- Body: 모든 응답에 body가 있는 것은 아니다. 응답이 성공했다면 body는 필요하지 않다.
4. HTTP Request Method
4-1. GET
가장 널리 쓰이는 요청 방법이다. 말 그대로 서버의 특정 자원에서 데이터를 get하는 방법.
4-2. POST
클라이언트 쪽에서 자원을 생성/수정하기 위한 데이터를 보낼 때 사용된다. 보내진 데이터는 서버에 저장된다.
4-3. DELETE
말 그대로 서버에 저장되어 있는 데이터를 지우기 위한 요청이다.
4-4. PUT
자원을 생성/수정하기 위한 요청으로 POST와 유사하지만, 가장 큰 차이점은 PUT요청은 데이터를 변형시키지 않는다는 점이다.(idempotent)
5. Response Status Codes
서버에서 요청에 응답할 때는 반드시 상태 코드와 함께 응답한다. 개발자는 이 코드를 통해 응답이 제대로 이루어졌는지, 프론트와 백 어디에 문제가 있는지 파악할 수 있다.
5-1. 200 OK
요청이 정상적으로 처리되었음을 의미한다. 요청 방법에 따라서는,
- GET: 요청한 자원을 제대로 가져왔다.
- POST/PUT: 서버에 내용이 잘 저장되었다.
5-2. 201 Created
새로운 자원이 잘 생성되었다. 주로 POST/PUT 요청 뒤에 나타난다.
5-3. 400 Bad Request
유효하지 않은 문법으로 인해 서버가 요청을 이해하지 못함.
5-4. 401 Unauthorized
인증받지 못한 사용자가 요청했을 때의 응답.
5-5. 403 Forbidden
사용자가 내용에 접근할 권한이 없음. 401과 다르게 사용자의 정보가 서버에 있다.
5-6. 404 Not Found
요청에 대한 자원을 서버가 찾을 수 없음. 인가받지 않은 사용자에게 자원의 존재를 숨기기 위해 403 대신 사용하는 경우도 있다.
5-7. 500 Internal Server Error
서버에서 뭔가 문제가 생겼을 때 나타난다.
6. HTTPS
HTTP의 보안적 문제점을 해결하기 위해 등장한 HTTPS는 S가 Over Secure Socket Layer를 뜻한다. 그동안 HTTP는 데이터를 암호화하지 않고 전송해 왔기 때문에 해커의 위협에 취약한 상태였다. 이를 보완하고자 HTTPS가 탄생했고, SSL 인증서를 통해 보안을 강화하였다.
6-1. SSL
SSL인증서는 클라이언트와 서버간 통신을 제 3자가 보장해주는 전자문서이다. 클라이언트가 서버에 접속하면 서버는 인증서를 전달하고, 클라이언트의 브라우저는 인증서를 발급하는 회사들의 리스트가 저장하고 있기 때문에 인증서가 안전한지 확인할 수 있다.
6-2. SSL의 암호화 방식
- 대칭키
대칭키 방식은 암호화를 할 때와 암호화 된 것을 푸는 복호화를 할 때 사용하는 키가 동일한 방식이다. 그렇기 때문에 속도는 빠르지만, 어느 한 쪽의 키만 유출되어도 암호를 복호화 할 수 있기 때문에 안전하지 못하다. - 공개키
대칭키의 단점을 해결하기 위해 나온 것이 공개키 방식이다. 공개키 방식은 A키로 암호화하면 B키로 복호화할 수 있고 B키로 암호화하면 A키로 복호화할 수 있는 방식이다. 이 두 키를 공개키와 비공개키로 나누어 비공개키는 자신이 보관하고 공개키는 타인에게 제공한다. 그러면 설사 한 쪽이 유출되더라도 복호화가 불가능하기 때문에 안전하다.
