HTTP란
- Hypertext Transfer Protocol의 약자로 시스템들 사이에 통신을 주고받게 해주는 통신규약
1. client-server 모델을 따르며
2. request/response 의 구조로 이루어짐
3. TCP/IP 기반으로 작동하며
4. 비연결성, 무상태성의 특성을 가짐
5. 평문(text)로 데이터를 주고받음
client-server 모델과 request/response 구조
클라이언트(client) : 서비스를 요청(request)하는 쪽
서버(server) : 요청된 서비스를 처리하고 응답(response)하는 쪽
-
클라이언트가 http request를 서버에 보내면,
request message (요쳥 메시지)
- *method, path, *HTTP version // start line
- headers
- body
이렇게 생긴 요청 메시지를 서버에 보내면 -
서버는 http response를 클라이언트에 보내줌
response message (응답 메시지)
- HTTP version, *status code, status message // status line
- headers
- body
이렇게 생긴 응답 메시지를 클라이언트로 보내줌
Connectionsless(비연결성)과 Stateless(무상태성)
- 이렇게 요청/응답이 한번 이루어지면 연결을 끊어버림 -> 비연결성
- 덕분에 많은 요청을 효율적으로 처리함
- 하지만 연결을 끊었기 때문에 클라이언트의 이전상태를 기억하지 못함 -> 무상태성
- 로그인 이라던지, 클라이언트의 이전상태를 서버는 알 수 없음
- 이런 특성을 보완하기 위해 cookie나 session, jwt등을 사용함
HTTPS
- TCP/IP는 도청이 가능함
- 패킷을 수집하면 text형식으로 주고받는 데이터까지 볼 수 있기 때문에 보안에 취약함
- 이를 위해 암호화를 추가한 프로토콜이 HTTPS
- ssl(secure socket layer)프로토콜을 이용함으로써 암호화되고 인증서로 보증된 통신을 할 수 있도록 HTTP에 보안기능을 더한 것
SSL
- ssl인증서 : 통신에 대해 제3자가 보증해주는 문서
- 클라이언트와 서버간의 통신에서 ssl이라는 계층이 추가됨
- 연결이 이루어지면 서버는 클라이언트의 인증서를 확인하고 신뢰할 수 있는 통신인지를 판단함
- ssl에서 사용하는 암호화 종류
- 대칭키 암호화
- 암/복호화에 필요한 키가 같음
- 대칭키가 유출되면 누구나 복호화가 가능해짐
- 그래서 공개키 방식을 사용
- 공개키 암호화
- 비대칭 암호화 방식으로 암/복호화에 필요한 키가 쌍으로 존재하고 하나는 공개키로 다른 사람이 알 수 있는 키, 다른 하나는 비공개키로 소유자만 알 수 있는 키로 존재함
- 공개키로 암호화 하고 수신자의 비공개키로 복호화 하는건 수신인이 명시되고,
- 발신자의 비공개키로 암호화하고 공개키로 복호화 하는 건 발신인이 명시됨
- 대칭키 암호화
*HTTP method
- GET : 클라이언트가 서버에게 리소스를 요청할 때 사용(주로 조회)
- POST : 데이터 처리를 요청할 때 사용(주로 생성)
- PUT : 리소스를 대체할 때 사용(대체할 리소스가 없으면 생성)
- DELETE : 리소스를 제거할 때 사용(주로 삭제)
- PATCH : 리소스의 일부분을 수정(잘안씀)
GET & POST
GET 요청은
- 서버에 리소스를 요청할 때 필요한 정보를 전달할 때
URL 뒤에 Query String을 추가함 - 이렇게 전달하면 쿼리스트링이 브라우저 히스토리에 남아 캐싱이 가능해짐(같은 요청이 있을 때 빠르게 접근할 수 있음)
- 쿼리스트링은 key-value 쌍으로 파라미터를 포함하는데
- url상에 이러한 쿼리스트링이 포함되므로 노출되는 위험성이 있음
POST 요청은
- 요청에 필요한 정보를 전달할 때 Body 부분에 포함시킴
- 캐싱이 불가능하고, url상에 노출되는 정보는 없음
- body로 전달된 데이터를 서버가 처리하는 요청이며
- '처리'라 함은 생성 뿐만 아니라, 변경하거나 특성 프로세스를 처리할 수도 있음
*HTTP version
버전별 특징을 간략히 정리함
HTTP 1.0
연결 한 번에 하나의 요청만 가능
3 way handshake - 데이터 하나 받고 - 4 way handshake
HTTP 1.1
tcp세션 유지가 가능해짐
Persistent Connection
-> 연결된 상태에서 여러번 요청 가능
Pipelining
-> 요쳥을 하고 응답을 받을때까지 아무것도 할 수 없음
파이프라인이 적용되면 여러 요청을 순차적으로 보내고 순차적으로 받게 됨
3개의 요청을 보내면 3개의 응답을 받아야 다른 일을 할 수 있음
응답시간이 길어지면 클라이언트가 아무것도 할 수 없는 상태가 됨(holb)
HTTP 2.0
멀티플렉싱 지원
메시지 전송방식의 변화
응답 대기 동안 다른 일을 할 수 있음
서버푸시
html과 css를 각각 요청해서 받았었는데
이제 html요청하면 css도 같이 줌
미리 리소스를 로드해서 대기시간을 줄임
헤더압축
헤더의 크기를 줄이고자 허프만인코딩을 사용하는 hpack압충방식을 도입
HTTP 3.0
TCP 위에서 작동하던 것들이 UDP위에서 돌아감
UDP에 TLS라는 전송계층 보안을 적용, 신뢰성을 향상시킴
네이버는 2.0과 3.0을 혼용하고, 구글은 3.0으로 서비스함
*Status code
클라이언트로부터 받은 요청을 서버가 처리하고
이에 대한 상태를 나타내는 코드를 응답 헤더에 포함함으로써
response(응답)을 받은 클라이언트가 알맞은 대응을 할 수 있도록 함
- 1xx (정보): 요청을 받았으며 작업을 계속함
- 2xx (성공): 클라이언트가 요청한 동작을 성공적으로 처리함
- 3xx (리다이렉션): 요청을 완료하기 위해 추가 작업 조치가 필요함
- 4xx (클라이언트 오류): 클라이언트의 요청에 문제가 있음
- 5xx (서버 오류): 유효한 요청에 대해 서버가 처리하지 못함
자주 보는 응답코드
| code | message | 의미 |
|---|---|---|
| 200 | OK | 요청이 성공 |
| 201 | Created | 리소스 생성 성공 |
| 400 | Bad Request | 잘못된 요청(잘못된 데이터 형식 등) |
| 401 | Unauthorized | 인증되지 않은 요청(로그인 안하고 접근하는 등) |
| 403 | Forbidden | 권한이 없는 요청(인증된 상태에서 권한이 없는 리소스에 접근 등) |
| 404 | Not Found | 요청된 리소스를 찾을 수 없음(존재하지 않는 route에 요청 등) |
| 502 | Bad Gateway | 서버에서 예상치못한 에러 발생(예외처리 되지않은 오류 발생 등) |
더 정리할 것들
tcp/ip 계층
tcp, udp 프로토콜
3,4 handshake
refer
https://lollolzz.tistory.com/6
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
https://www.geekscoding.com/cote/tips
