📒 HTTP 프로토콜
HyperText Tranfer Protocol ; 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜
애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.
🟠 작동방식
서버/클라이언트 모델로 클라이언트에서 Request 하면 서버에서 요청을 처리해서 response 한다.
실제 전송은 TCP를 통해 이루어지며 포트는 80번을 이용한다.
Connectionless & Stateless 방식이다.
서버에 연결하고 요청해서 응답을 받으면 연결을 끊어버린다. 기본적으로 자원 하나에 대해서 하나의 연결을 만든다.
장점 : 불특정 다수를 대상으로 하는 서비스에 적합하다. 많은 이용자가 사용하더라도 접속 유지를 최소한으로 해 더 많은 유저의 요청을 처리할 수 있다.
단점 : 연결을 끊어버리기 때문에 클라이언트의 이전 상태를 알수가 없다. HTTP는 cookie를 이용해서 이 문제를 해결하고 있다.
🟠 URI
클라이언트 소프트웨어 (IE, Chrome, FireFox....) 는 URI를 이용하여 자원의 위치를 찾는다.
URI는 HTTP와 독립된 다른 체계로 HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜이다.
www 상에서 접근하고자 하는 자원의 위치를 나타내기 위해서 사용한다.
URI 예시 :
http -> 자원에 접근하기 위해 http 프로토콜을 사용한다.
www.naver.com -> 자원의 인터넷 상에서의 위치인 www.naver.com 도메인은 ip주소로 변환되고 ip 주소로 서버 위치를 찾음.
index.php -> 요청할 자원의 이름이다.
🟠 메세지 구조
| 구분 |
| request |
| response |
| Body |
🟠 method
메서드는 요청의 종류를 서버에게 알려주기 위해서 사용한다.
GET : 정보를 요청하기 위해서 사용 (SELECT)
POST : 정보를 삽입하기 우해서 사용 (INSERT)
PUT : 정보를 업데이트하기 위해서 사용
DELETE : 정보를 삭제하기 위해서 사용
HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
OPTIONS : 웹 서버가 지원하는 메서드의 종류를 요청한다.
TRACE : 클라이언트의 요청을 그대로 반환
각 용도에 맞는 메서드가 준비되어있지만 GET과 POST만으로도 모든 요청을 표현할 수 있다.
RESTful API 서버의 경우에는 GET, POST, DELETE, PUT 을 명시적으로 구분한다.
🟠 HTTP 상태 코드
응답 메세지에서 Start-line에 표기되는데 요청에 대한 처리 결과를 알려준다.
1XX : 정보성
2XX : 성공 - 서버가 요청을 성공적으로 처리했음
3XX : 리다이렉션
4XX : 클라이언트 요청에 오류가 있음
400 : 잘못된 요청으로 주로 헤더 포맷이 HTTP 규약에 맞지않을경우
403 : 서버가 요청을 거부하고 있다.
404 : 찾을 수 없음 - 요청 자원이 서버에 존재하지 않는다.
5XX : 서버 오류
- Keep Alive 기능 지원 (HTTP 1.1 부터는 keep-alive 기능을 지원한다.)
기본적으로 HTTP는 하나의 연결에 하나의 요청을 하는 것이 기준이지만 요즘 한 페이지에 수십개의 데이터가 있기때문에 연결을 맺고 끊는 과정이 계속 반복되어 비효율적이다. Keep-alive 설정을 하면 지정된 시간동안 연결을 끊지않고 요청을 계속해서 보낼 수 있다.
Conncetion: Keep-Alive
Keep-Alive:timeout=5, max=200
참고자료 ::
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview
https://developer.mozilla.org/ko/docs/Web/HTTP/Messages#%EB%B3%B8%EB%AC%B8
https://noahlogs.tistory.com/34?category=827412
