웹 개발자가 알아야 되는 HTTP 프로토콜
웹 개발 공부를 시작하려고 한다. 그런데 이전 학부생때 공부했던 내용들이 기억이 나질 않는다!
그러던 와중에 좋은 글을 찾아 내용을 정리 및 보충 하였다. 출처는 아래쪽에 표시해 두었다.
프로토콜이란?
프로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계입니다. 기기 간 통신은 교환되는 데이터의 형식에 대해 상호 합의를 요구합니다. 이런 형식을 정의하는 규칙의 집합을 프로토콜이라고 합니다.
즉 상호 통신 규약 및 약속 입니다.
HTTP 프로토콜이란?
HTTP(Hypertext Transfer Protocol)은 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다.
HyperText - 문서와 문서가 링크로 연결되도록 하는 태그로 구성된 언어입니다.
Transfer - 전송을 의미하며 보내는 주체와 받는 주체가 있어야 성립할 수 있습니다.
Protocol - 통신규약으로 보통 요청이냐 응답이냐에 따라 다른 구조를 가지고 있습니다.
웹에서는 모든 데이터 교환의 기초로 HTTP 프로토콜을 사용하고 있습니다.
또한 HTTP 프로토콜은 상태가 없는(stateless) 프로토콜 입니다. 상태가 없다는 말은 통신이 이뤄져도 클라이언트와 서버는 연결되어 있는 것이 아니고 데이터를 주고 받기 위한 각각의 데이터 통신이 서로 독립적으로 관리가 된다는 의미입니다. 좀 더 쉽게 말해서 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말입니다.
데이터 요청이 서로 관련이 없다는 의미는 매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 한다는 의미입니다.비유를 하자면, 마치 이미 자기소개를 한 사람에게 계속해서 똑같은 내용으로 자기소개를 해야하는 것과 같습니다.
이로 인하여 여러번의 통신(요청/응답)의 진행과정에서 연속된 데이터 처리가 필요한 경우(ex: 온라인 쇼핑몰에서 로그인 후 장바구니 기능)를 위해 로그인 토큰 또는 브라우저의 쿠키, 세션, 로컬 스토리지 같은 기술이 필요에 의해 만들어 졌습니다. (세션/저장소 같은 방식으로 이용하여 로그인 정보를 기억하는것 처럼 보이게합니다.)
HTTP 프로토콜은 일반적으로 TCP/IP 통신 위에서 동작하며 기본 포트는 80번입니다.
HTTP 패킷
HTTP 통신의 요청과 응답을 그 정보들을 패킷(Packet)에 넣어 보냅니다.
패킷 구조 : Header / Body
Header : 보내는 사람의 주소, 받는 사람의 주소, 패킷 생명시간
Body : 실제 전달하고자 하는 내용
HTTP 요청(Request)과 응답(Response)
Server-Client 관계에서는 Client가 요청(Request)하면 서버가 요청을 처리한 후 Cleint에게 응답(Response)합니다.
웹 관점으로 보면 Client는 요청을 보내는 쪽으로 브라우저(크롬, edge, firefox 등)를 의미하고, Server는 요청을 받는 쪽을으로 일반적으로 데이터를 보내주는 원격지의 컴퓨터를 의미합니다.
웹에서는 이 과정을 아래의 이미지같이 TCP/IP 통신 위에서 HTTP 방식을 사용하여 패킷(Packet)에 넣어 보냅니다.
브라우저의 요청 (Request)
앞서 본 내용처럼 브라우저가 서버에 요청을 할 때, 간략하게 보면 URL(Uniform Resource Locators)과 HTTP 요청 메서드(Http Request Methods)를 포함하여 요청하게 됩니다.
URL(Uniform Resource Locators)은 서버에 특정 데이터를 요청하는 역할로 인터넷에서 웹 페이지, 이미지, 비디오 등 리소스의 위치를 가리키는 문자열입니다.
HTTP 요청 메서드(Http Request Methods)는 요청하는 데이터에 특정 동작을 수행하도록 합니다.
일반적으로 HTTP Verbs라고도 불리우며 아래와 같이 주요 메서드를 가지고 있습니다.
● GET : 존재하는 자원에 대한 요청 (조회)
- 이름 그대로 어떤 데이터를 서버로 부터 받아(GET)올 때 주로 사용하는 메소드
- 데이터를 받아오기만 할 때 사용
- 가장 간단하고 많이 사용되는 HTTP 메소드
(우리가 웹페이지를 띄울 때 필요한 정보들을 모두 GET메소드로 요청을 보내서 받아온 응답을 화면에 띄우는 것입니다.)
- 대부분 body를 포함하지 않습니다.
● POST : 새로운 자원을 생성
- 데이터를 생성 / 수정 할 때 주로 사용되는 메소드
- 데이터를 생성 및 수정 할 때 많이 사용되기 때문에 대부분의 경우 요청에 body가 포함되서 보내집니다.
● PUT : 존재하는 자원에 대한 변경
● DELETE : 존재하는 자원에 대한 삭제
이와 같이 데이터에 대한 조회, 생성, 변경, 삭제 동작을 HTTP 요청 메서드로 정의할 수 있습니다. 참고로 때에 따라서는 POST 메서드로 PUT, DELETE의 동작도 수행할 수 있습니다. (대부분의 환경에서는 GET, POST방식을 주로 사용합니다.)
기타 요청 메서드는 다음과 같습니다.
- HEAD : 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않음
- OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 사용
서버의 응답(Response)
서버는 브라우저의 요청에 대한 응답으로 크게 상태 코드(HTTP Status Code)와 응답 Body 정보를 보내줍니다.
여기서 상태 코드는 브라우저의 요청에 대한 응답의 결과를 의미합니다. 상태 코드를 이용하여 결과에 따른 추가적인 로직을 구현하여 처리할 수도 있습니다. 주요 상태 코드는 아래와 같습니다.
2xx - 성공
200번대의 상태 코드는 대부분 성공을 의미합니다.
- 200 : GET 요청에 대한 성공
- 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
- 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
- 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환
3xx - 리다이렉션
300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.
- 301 : Moved Permanently, 요청한 자원이 새 URL에 존재
- 303 : See Other, 요청한 자원이 임시 주소에 존재
- 304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인
4xx - 클라이언트 에러
400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생합니다. 가장 익숙한 상태 코드는 404 코드입니다. 요청한 자원이 서버에 없다는 의미죠.
- 400 : Bad Request, 잘못된 요청
- 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
- 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지 (유저가 해당 요청에 대한 권한이 없다는 의미)
- 405 : Method Not Allowed, 허용되지 않은 요청 메서드
- 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌
5xx - 서버 에러
500번대 상태 코드는 서버 쪽에서 오류가 난 경우입니다. (API 개발을 하는 백엔드 개발자들이 싫어하는 코드)
- 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
- 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우
HTTP Request Message 및 HTTP Response Message의 상세 구조
앞서 설명했던 내용과 더불어 각 Message의 상세 구조를 보면 아래와 같습니다.
HTTP Request Message
HTTP Request는 크게 세 부분으로 구성되어 있습니다.
1. Start Line: 요청의 첫번째 줄에 해당합니다. 이 시작 줄도 세 부분으로 구성되어 있습니다.
(GET /login HTTP/1.1)
- HTTP Method: 해당 요청이 의도한 액션을 정의하는 부분 (GET 부분)
- Request target: 해당 Request가 전송되는 목표 URL (/login 부분)
- HTTP Version: 사용되는 HTTP 버전, 주로 1.1 버전이 널리 쓰임 (1.1 부분)
2. Headers: 해당 요청에 대한 추가 정보(메타 데이터)를 담고있는 부분입니다.
Key : Value 값으로 되어 있습니다. (JavaScript의 객체, Python의 딕셔너리, 자바의 Map 형태를 생각하면 됩니다.)
자주 사용되는 Headers** 의 정보에는 아래와 같습니다.
Headers: {
Host: 요청을 보내는 목표(타겟)의 주소. 즉, 요청을 보내는 웹사이트의 기본 주소 (ex. www.naver.com)
User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome, firefox, safari)
Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
Content-Length: body 내용의 길이
Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰을 Authroization에 저장
}
3. Body: 해당 요청의 실제 내용. 주로 Body를 사용하는 메소드는 POST 입니다.
ex) 로그인 시에 서버에 보낼 요청의 내용
Body: {
"user_email": "jun.choi@gmail.com"
"user_password": "wecode"
}
Http Request Message
HTTP 규약에 따른 응답의 구조도 또한 크게 세 부분으로 구성되어 있습니다.
1. Status Line: 응답의 상태. 응답은 요청에 대한 처리상태를 클라이언트에게 알려주면서 내용을 시작합니다.
마치, 편지의 응답에 "응. 잘 지냈어" 라고 안부 인사를 건네는 것과 같습니다.
응답의 Status Line 도 세 부분으로 구성됩니다.
- HTTP Version: 요청의 HTTP버전과 동일
- Status Code: 응답 메세지의 상태 코드
- Status Text: 응답 메세지의 상태를 간략하게 설명해주는 텍스트
HTTP/1.1 200 SUCCESS
해석: HTTP 1.1 버전으로 응답하고 있으며, 프론트엔드에서 보낸 요청에 대해서 성공했기 때문에
200 (성공) 상태 메세지를 전송합니다.
HTTP/1.1 404 Not Found
해석: HTTP 1.1 버전으로 응답하고 있으며, 프론트엔드에서 보낸 요청(ex. 로그인 시도)에 대해서
유저의 정보를 찾을 수 없기 때문에(Not Found) 404 (실패) 상태 메세지를 전송합니다.
2. Headers: 요청의 헤더와 동일합니다. 응답의 추가 정보(메타 데이터)를 담고있는 부분입니다. 다만, 응답에서만 사용되는 헤더의 정보들이 있습니다. (ex. 요청하는 브라우저의 정보가 담긴 User-Agent 대신, Server 헤더가 사용)
3. Body: 요청의 Body와 일반적으로 동일합니다. 요청의 메소드에 따라 Body가 항상 존재하지 않듯이. 응답도 응답의 형태에 따라 데이터를 전송할 필요가 없는 경우엔 Body가 없을 수도 있습니다.
가장 많이 사용되는 Body 의 데이터 타입은 JSON(JavaScript Object Notation) 입니다.
ex) 로그인 요청에 대해 성공했을 때 응답의 내용
Body: {
"message": "SUCCESS"
"token": "tkdrq23zxc@9df0acvcxd" (암호화된 유저의 정보)
}
아래는 일반적으로 사용하는 프로토콜과 기본 포트를 정리하였습니다.
Protocol 종류
일반적인 프로토콜
Http : Hyper Text Transer Protocol
Https : secure Hyper Text Transer Protocol
TCP/IP : 프로토콜을 가지고 서버와 클라이언트 사이의 파일 전송을 하기 위한 프로토콜
FTP : File Transfer Protocol, 파일 전송 프로토콜
Telnet : Terminal Network
SSH : Secure Shell
보안된 소켓 통신을 위한 프로토콜을
SMTP : Simple Mail Transfer Protocol
기타
TCP/UDP : Transmission Control Protocol/User Datagram Protocol
IP : Internet Protocol