HTTP(HyperText Transfer Protocol)
- HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜
- 웹에서 이루어지는 모든 데이터 교환의 기초
- 클라이언트-서버 프로토콜 : 클라이언트 요청을 생성하기 위해 연결을 연 다음 응답을 받을 때 까지 기다리는 모델
- 데이터 스트림이 아닌, 개별적인 메시지 교환으로 통신
- request(요청) : 클라이언트(브라우저)에 의해 전송되는 메시지
- response(응답) : 서버에서 응답으로 전송되는 메시지
- 애플리케이션 계층 프로토콜
- 신뢰 가능한 전송 프로토콜을 사용한다.
- 주로 TCP TLS(암호화된 TCP) 사용
프록시(Proxy)
- 웹 브라우저와 서버 사이에 있는 많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다.
- 애플리케이션 계층에서 동작하는 컴퓨터/머신
- 프록시로 다양한 기능 수행 가능
- 캐싱
- 필터링
- 로드밸런싱
- 인증
- 로깅
HTTP 특징
- 간단한 사용
- 확장 가능 : HTTP 헤더를 통해 확장 가능
- 무상태(Stateless), 세션
- HTTP 쿠키를 통해 상태가 있는 세션을 만든다.
- 헤더 확장성을 사용해서 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키 추가
HTTP 통신 과정
1. TCP 연결을 연다. : 요청을 보내거나 응답을 받는 데 사용
2. HTTP 메시지 전송(request)
- HTTP2는 캡슐화되어 직접 읽기 불가능
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
3. 서버가 보낸 응답을 읽는다.
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
4. 연결을 닫거나 다른 요청을 위해 재사용
HTTP Message 구조
- 시작 줄(start-line) : HTTP 요청 / 요청에 대한 성공 또는 실패
- HTTP 헤더 : 요청에 대한 설명 / 메시지 본문에 대한 설명
- 빈 줄 : 요청에 대한 모든 메타 정보가 전송되었음을 알린다. (헤드와 본문 사이)
- 본문(optional) : 요청과 관련된 데이터(HTML form) / 또는 응답과 관련된 문서가 선택적으로 들어간다.

HTTP Requset
- 클라이언트가 서버로 전달하는 메시지
- request line : HTTP method + url + http version
- header(헤더)
- request header
- client의 IP, 사용 언어(accept language), content type(파일 형식), referer(이전 페이지 주소)
- general header : 메시지 전체에 적용, connection(네트워크 접속 유지할지 유무)
- entity header : 요청 본문에 적용, content-length(요청과 응답 메시지의 본문 크기)
- request header
- request body : query string의 정보
HTTP Resonse
- Status line(Response Line)
- http/1.1 (프로토콜 버전) + status code 상태 코드(ex.200) + 상태 텍스트(ex.OK)
- response header
- 결과 데이터에 대한 설명 : Encoding, content-type(MIME(HTML, Image, video), size, server 설명(아파치, 톰캣 등등)
- response body
<HTML>
<HEAD>
<BODY>
...
HTTP Request Method
- GET : 리소스를 받기 위해 사용. URI 형식으로 서버측에 리소스 요청
- POST : 내용 및 파일 전송. 클라이언트에서 서버로 어떤 정보를 제출하기 위해 사용
- PUT : 리소스 갱신.
- DELETE : 리소스 삭제 -> 실제로는 클라이언트에게 리소스 삭제 권한 X
- HEAD : 메시지 헤더 정보를 받기 위해 사용. 응답 메시지에 Body는 비어있고 header 정보만 받는다.
- CONNECT : 클라이언트와 서버 사이의 중간 경유를 위해 사용. 보통 proxy으로 SSL 통신할 때 사용
- OPTIONS : 서버 측 제공 메소드에 대한 질의를 위해 사용. 웹 서버에서 지원하는 메소드를 알기 위해 사용
- TRACE : 요청 리소스가 수신되는 경로를 보기 위해 사용
- PATCH : 리소스의 일부분을 갱신하기 위해 사용. PUT과 유사하지만 모든 데이터 갱신이 아니라 일부분만 수정할 때 사용
HTTP Status Code
- 응답 상태 코드로 성공/실패 여부 확인
- 10x : 정보 확인
- 20x : 통신 성공
- 30x : 리다이렉트
- 40x : 클라이언트 오류
- 50x : 서버 오류
성공 응답
상태코드 | 이름 | 의미 |
200 | OK | 요청 성공(GET) |
201 | Created | 생성 성공(POST) |
202 | Accepted | 요청 수신O, 리소스 처리X 배치 프로세스를 하고 있는 경우를 위해 사용 |
204 | No Content | 요청 성공O, 내용 없음 |
리다이렉션 메시지
상태코드 | 이름 | 의미 |
300 | Multiple Choice | 요청 URI에 여러 리소스가 존재 |
301 | Move Permanently | 요청 URI가 변경되었음을 의미 |
304 | Not Modified | 요청 URI의 내용이 변경X 캐시 목적으로 사용한다. 클라이언트는 계속해서 응답된 캐시 버전을 사용할 수 있다. |
클라이언트 오류
상태코드 | 이름 | 의미 |
400 | Bad Request | 잘못된 요청. API에서 정의되지 않은 요청 |
401 | Unauthorized | 인증 오류 |
403 | Forbidden | 권한 밖의 접근 시도 (401와는 다르게 서버는 클라이언트가 누구인지 알고 있음) |
404 | Not Found | 요청받은 리소스를 찾을 수 없음 (리소스를 숨기기 위해 403으로 전송할 수도 있음) |
405 | Method Not Allowed | API에서 정의되지 않은 메소드 호출 |
429 | Too Many Requests | 요청 횟수 상한 초과 |
서버 에러 응답
상태코드 | 이름 | 의미 |
500 | Internal Server Error | 서버 내부 오류 자세한 오류를 알 수 없는 상황 |
502 | Bad Gateway | 게이트 웨이 오류 |
503 | Service Unavailable | 서비스 이용 불가 |
504 | Gateway Timeout | 게이트웨이 시간 초과 |
Socket(소켓)
- 두 프로그램이 서로 데이터를 주고 받을 수 있도록 양쪽에 생성되는 통신 단자
- 양방향 통신 : 서버와 클라이언트 양방향 연결이 이루어지는 통신
- 클라이언트도 서버로 요청을 보낼 수 있고, 서버도 클라이언트로 요청을 보낼 수 있다.
- 실시간 서비스 : 영상 스트리밍, 실시간 채팅
- 웹 소켓 프로토콜 : 최초 연결을 요청할때만 HTTP 프로토콜 위에서 Handshaking 하기 때문에 http hedaer 사용한다.
HTTP
- 파일을 전송하는 프로토콜
- JSON, Image 등등 전송
- 단방향 통신 : 클라이언트가 요청을 보내고 서버가 응답을 하는 방식의 통신
'ETC > 이론 정리' 카테고리의 다른 글
[Docker] 도커 - 컨테이너, 이미지, 파일 (0) | 2023.12.04 |
---|---|
[Github] Github Action 깃헙 액션 (0) | 2023.07.16 |
[WEB] CSRF(Cross Site Request Forgery), XSS(Cross Site Scription) (0) | 2022.10.06 |
[WEB] 인증 방식 - OAuth(Open Authorization), JWT(Json Web Token) (0) | 2022.10.06 |
[Kafka] 아파치 카프카란? Apache Kafka (0) | 2022.10.01 |