
분산 하이퍼미디어 환경에서 빠르고 간편하게 데이터를 전송하는 프로토콜이다.
HTTP는 80번 포트를 사용하도록 정의되어 있다.
HTTP 서버는 80번 포트에서 대기하고, 클라이언트는 TCP를 사용해 연결을 설정한다.
웹 브라우저는 사용자가 요청하는 자원을 가리키는 URL 주소에 사용할 프로토콜을 표현한다.
ex. http://www.korea.co.kr
-> HTTP 서버에로부터 웹 정보를 얻는다는 의미이다.
이외에도 FTP 서버에 접근 하려면 ftp://~, 텔넷 서버에 접근하려면 telnet://~ 형식으로 표현하면 된다.
출처 : https://wp-rocket.me/blog/reduce-http-requests-speed-wordpress-site/
비상태 연결(Stateless Connection)"은 각각의 요청이 이전 요청과 독립적으로 처리되는 연결 형태를 의미한다.
TCP 연결이 설정되면서 요청과 응답이 진행되고, 응답 이후에는 TCP 연결이 해제되기 때문에 연결 존재에 따른 상태정보가 존재하지 않는다. 따라서 HTTP는 무상태 프로토콜로 분류된다.
- 무상태 프로토콜 (Stateless Protocol)
서버가 클라이언트의 상태를 본존하지 않는 다는 것을 의미한다.
즉, 각각의 요청은 서버에 의해 독립적으로 처리되며 이전 요청의 상태 정보는 영향을 미치지 않는다.
HTTP의 요청·응답 메시지는 MIME(Multipurpose Internet Message Extension) 유사 구조를 사용해 데이터를 전송한다. 즉, 웹 브라우저에서 발생하는 모든 메시지는 MIME 개체와 거의 유사하게 표현되며, 서버에서 전송된 데이터도 MIME 개체로 표현된다.
- MIME
MIME(Multipurpose Internet Mail Extensions)은 전자우편의 데이터 형식을 정의한 표준 포맷이다. MIME type은 ASCII 코드만 전송할 수 있었던 전자우편으로 이미지, 동영상, 엑셀 등의 바이너리 데이터를 주고받기 위해 개발되었는데, 현재는 HTTP 통신에서 데이터 형식을 식별하기 위해 사용된다.
MIME 타입은 일반적으로 슬래시(/)로 구분된 type과 subtype 두 부분으로 구성된다. 또한 이 사이에는 공백이 없다.
ex.type/subtype
HTTP의 MIME 유사 개체와 RFC 2045에 기술된 MIME 개체의 차이
HTTP의 MIME 유사 개체에는 Content-Length라는 헤더 필드가 존재한다.
Content-Length는 개체를 전송하는데 필요한 바이트 수이다.
Content-Transfer-Encoding 헤더 필드 대신 Content-Encoding과 Transfer-Encoding 필드를 사용한다.
Content-Transfer-Encoding
Content-Transfer-Encoding은 MIME 형식에서 사용되는 헤더 필드이다. 해당 헤더는 전자 메일의 본문 부분이 어떻게 인코딩되었는지를 나타낸다.
예를 들어, base64로 인코딩된 이미지나 첨부 파일의 경우, 이 헤더 필드에 해당 인코딩 방식이 명시된다.
ex. Content-Transfer-Encoding: base64
Content-Encoding
Content-Encoding 헤더 필드는 메시지 본문의 압축 방법을 나타낸다. 해당 헤더는 웹 서버가 클라이언트에게 전송하는 콘텐츠가 어떤 압축 방법으로 인코딩되었는지를 알려준다.
예를 들어, gzip이나 deflate와 같은 압축 알고리즘을 사용하여 콘텐츠를 압축할 때, 해당 헤더 필드에 해당 알고리즘 이름을 포함시킨다.
ex. Content-Encoding: gzip 또는 Content-Encoding: deflate
Transfer-Encoding
Transfer-Encoding 헤더는 메시지의 전송 인코딩을 나타낸다. 해당 헤더는 메시지의 전송 중에 콘텐츠가 어떻게 인코딩되었는지를 명시한다.
예를 들어, HTTP/1.1에서는 여러 청크로 메시지를 전송할 때 chunked 값을 사용하여 표시된다. 이를 통해 서버는 데이터를 여러 조각으로 나누어 전송할 수 있다.
ex. Transfer-Encoding: chunked
클라이언트가 서버에 보내는 요청 메시지(Request Message)의 구조는 다음과 같이 요청문, 헤더, 바디로 구성된다.
출처 : https://www.studytonight.com/computer-networks/http-protocol
요청문의 내용은 <요청 메서드>, <URL>, <HTTP 버전> 세 부분으로 구성된다.
주요 요청 메서드
GET
클라이언트가 서버에게 URL이 가리키는 웹 문서의 내용을 전송하도록 요구한다. 문서 내용은 서버가 회신하는 응답 메시지의 바디에 포함된다.
HEAD
문서 내용보다는 특정 문서의 정보를 원할 때 사용한다.
POST
클라이언트가 서버에 데이터를 보내거나 리소스를 생성하기 위해 사용한다. 보통 게시판, 방명록처럼 사용자가 입력한 정보를 서버에 전달하는 용도로 사용한다.
PUT
클라이언트가 새로운 리소스를 생성하거나, 기존 리소스를 업데이트할 때 사용한다. 문서 내용은 바디에 포함된다.
cf.
출처 : https://www.fis.kr/ko/major_biz/cyber_safety_oper/attack_info/security_news?articleSeq=2504
ex. GET / HTTP/1.1
요청 메서드 : GET
URL : /
HTTP 버전 : HTTP/1.1
따라서, 해당 요청은 웹 서버의 최상위(/)에 위치한 자원을 얻고자 하며, 클라이언트가 HTTP 버전 1.1을 지원함을 알 수 있다. 요청문 밑의 헤더는 클라이언트와 서버 사이의 부가 정보를 전달하는 목적으로 사용되며, 형식은 <헤더 이름> : <헤더 값>이다.
클라이언트로부터 요청 메시지를 수신한 서버는 해당 요구를 처리한 후에 그 결과를 응답 메시지 형식으로 회신한다. 응답 메시지의 구조는 요청 메시지와 거의 동일하지만, 요청문 대신에 처리 결과를 의미하는 상태문(Status Line)이라는 용어를 사용한다.
출처 : https://www.studytonight.com/computer-networks/http-protocol
상태문의 내용은 <HTTP 버전>, <상태 코드>, <상태 이름>의 세 부분으로 구성된다.
HTTP 버전은 요청 메시지와 의미가 같고, 상태 코드와 상태 이름은 일반 인터넷 응용 프로그램과 구조가 같다.
HTTP 주요 상태 코드
출처 : https://www.studytonight.com/computer-networks/http-protocol