HTTP/HTTPS

HTTP (Hyper Text Transfer Protocol)

● HTTP(Hyper Text Transfer Protocol)란 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response)형식으로 정의한 프로토콜이다.

 

●팀 버너스 리(Team Berners-Lee)와 그의 팀이 제정한 이후, 현대 웹 서비스의 바탕이 되는 프로토콜로 자리잡았다.

 

● HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면, 서버가 응답하는 것이다.

 

● 웹 서버는 HTTP 서버를 HTTP 서비스포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환한다.

 

네트워크 포트와 서비스 포트

네트워크 포트(Network Port)란 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소를 의미한다. 포트에는 항구라는 의미가 있는데, 클라이언트가 서버의 포트에 접근하여 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보내는 장면을 연상하면 포트의 기능을 이해할 수 있다. 편의상, 네트워크를 설명하는 맥락에서는 네트워크를 생략하여 "포트"라고 부르기도 한다.

서비스 포트(Service Port)는 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트를 이른다. 예를 들어, HTTP가 80포트를 점유하고 있다면 HTTP의 서비스 포트는 80포트가 된다.

○ 포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따른다.
   →대표적으로는 TCP와 UDP가 있다.
○ 포트의 개수는 운영체제에서 정의하기 나름인데 현대의 윈도우나 리눅스, 맥 운영체제는 0번부터 65535번까지 총 65536개의 같은 수의 네트워크 포트를 사용한다.
○ 포트 중 0번부터 1023번 포트는 잘알려진 포트(Well-known port) 또는 특권 포트(Privileged port)라고 한다.
   →대표적으로 22번 포트에는 SSH, 80포트에는 HTTP, 443포트에는 HTTPS가 할당되어 있으며 잘 알려진 포트에서 서 비스를 실행하려면 관리자 권한이 필요하다.

---

HTTP 메세지

HTTP 요청과 응답

● HTTP 메세지 에는 클라이언트가 전송하는 HTTP요청, 그리고 서버가 반환하는 HTTP응답이 있으며 이들은 HTTP 헤드와 바디로 구성된다.

 

HTTP 헤드

● HTTP 헤드의 각 줄은 CRLF로 구분되며, 첫 줄은 시작줄(Start-line), 나머지줄은 헤더(Header)라고 부른다. 헤드의 끝은 CRLF한 줄로 나타낸다.

● 헤더는 필드와 값으로 구성되며 HTTP 메세지 또는 바디의 속성을 나타낸다. 하나의 HTTP메세지에는 0개이상의 헤더가 있을 수 있다.

 

HTTP 바디

● HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 바디에 담긴다.

 

HTTP 요청

● HTTP 요청은 서버에게 특정 동작을 요구하는 메세지 이다.

 

●서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토하고, 적절한 때만 이를 처리한다.

 

구조

 

1.시작줄

HTPP 요청의 시작줄은 메소드(Method), 요청URI(Reauest-URI), HTTP 버전으로 구성되며 각각은 띄어쓰기로 구분한다.

 

● HTTP 메소드의 종류

메소드	설명
GET	URI로 지정한 정보를 가져온다 파일의 경우 해당 파일의 내용을 되돌려 보내고, CGI 프로그램일 경우 프로그램 출력 데이터를 반송한다.
POST	클라이언트에서 서버로 데이터를 송신한다. 폼에 입력한 데이터를 송신한다.
HEAD	GET과 비슷하지만 HTTP 메세지 헤더만 반송하고 데이터의 내용을 돌래보내지 않는다. 파일 최종시간 갱신을 조사할 때 사용한다.
OPTION	통신 옵션을 통지하거나 조사 할때 사용한다.
PUT	URI로 지정한 서버의 파일을 치환한다. URI로 지정한 파일이 없는 경우에는 새로 파일을 작성한다.
DELETE	URI로 지정한 서버의 파일을 삭제한다.
TRACE	서버측에서 받은 request 라인과 헤더를 그대로 클라이언트에 반송한다. 프록시 서버 등을 사용하는 경우 리퀘스트가 치환되는 상태를 조사할 때 사용한다.
CONNECT	암호화한 메세지를 프록시로 전송할 때 사용한다.

 

2. 요청 URI

- 메소드의 대상을 나타낸다.

 

3. HTTP 버전

- 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타낸다.

 

GET 방식과 POST 방식의 차이

○ 사용 목적 
   1. GET : 서버의 리소스에서 데이터를 요청할때사용 [ ex) SQL 에서 SELECT문과 비슷]
   2. POST : 서버의 리소스를 새로 생성하거나 업데이트할 때 사용 [ ex) SQL 에서 Create문과 비슷]
○ 요청에 body의 유무
   1. GET : GET은 URL 파라미터에 요청하는 데이터를 담아보내기 때문에 HTTP 메시지에 body가 없음
   2. POST : POST는 body에 데이터를 담아보내기 때문에 HTTP 메시지에 body가 존재
       → GET 방식에 비해 보안성이 높음

HTTP 응답

● HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메세지 이다. 요청을 수행했는지, 하지 않았는지, 안했따면 이유는 무엇인지와 같은 상태정보 (Status), 그리고 클라이언트에게 전송할 리소스가 포함된다.

 

구조

 

시작줄

● HTTP 응답의 시작줄은 HTTP 버전, 상태코드(Status Code), 그리고 처리사유(Reason Phrase)로 구성되며 각각은 띄어쓰기로 구분된다.

 

HTTP 버전

● 서버에서 사용하는 HTTP 프로토콜의 버전을 나타낸다.

 

상태코드

● 요청에 대한 처리 결과를 세자릿수로 나타낸다. HTTP 표준인 RFC 2616은 대략 40여개의 상태코드를 정의하고 있는데 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류된다.

상태코드	설명	대표 예시
1XX	요청을 제대로 받았고, 처리가 진행중임
2XX	요청이 제대로 처리됨	- 200 : 성공
3XX	요청을 처리하려면, 클라이언트가 추가 동작을 취해야함	- 302 : 다른 URL로 갈것
4XX	클라이언트가 잘못된 요청을 보내어 처리에 실패	- 400 : 요청이 문법에 맞지않음 - 403 : 클라이언트가 리소스에 요청할 권한이 없음 - 404 : 리소스가 없음
5XX	클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패	- 500 : 요청을 처리하다가 에러가 발생 - 503 : 서버가 과부하로 인해 요청을 처리할 수 없음

 

처리사유

- 상태코드가 발생한 이유를 짧게 기술한 것이다.

 

HTTPS (HTTP over Secure socket layer)

● HTTP 의 응답과 요청은 평문으로 전달된다. 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있다. 예를 들어 로그인할 때 전송한 POST 요청에는 대개 이용자의 ID와 비밀번호가 포함된다. 공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있다.

 

● HTTPS 는 TLS(Transport Layer Scurity) 프로토콜을 도입하여 이런 문제점을 보완한다. TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP메세지를 암호화 한다. 공격자가 중간에 메세지를 탈취하더라도 이를 해석하는 것은 불가능하며, 결과적으로 HTTP통신이 도청과 변조로부터 보호된다.

○ 웹서버의 URL이 http://로 시작하면 HTTP 프로토콜을 사용
○ 웹서버의 URL이 https://로 시작하면 HTTPS 프로토콜 사용

○ TLS (Transport Layer Security) ?
   → 서버와 클라이언트 사이에 오가는 HTTP 메시지를 암호화 한것
   → 공격자가 중간에 메시지를 탈취하더라도 해석하는 것은 불가능 하며 HTTP 통신이 도청과 변조로 부터 보호된다는 장점이 있음

HTTP/HTTPS 비교