ch2_07. HTTP 요청과 응답 - 이론(1)

1. 프로토콜(protocol)이란?
2. HTTP(Hyper Text Transfer Protocol)란?
3. HTTP 메시지
4. HTTP 메세지 - 응답 메시지
5. HTTP 메세지 - 요청 메시지
6. HTTP 메세지 - GET, POST

---

1. 프로토콜(protocol)이란?

protocol은 서로 간의 통신을 위한 약속, 규칙이다. 컴퓨터에서만 쓰이는 용어는 아니다.

 

컴퓨터에서 말하는 protocol은 '주고받을 데이터에 대한 형식을 정의한 문서'이다. 데이터를 어떻게 주고받을지 약속하지 않으면 데이터가 어디서부터 어디까지인지 혹은 어떤 내용인지 해석할 수 없다. 따라서 데이터를 주고받을 때 필요한 서로 간의 약속이 쓰인 문서가 있어야 한다.

 

protocol은 '주고받을 데이터에 대한 형식을 정의한 문서'이다. 이는 business letter와 비슷하다. business letter 맨 위에는 받는 사람, 직책, 주소, 날짜 등 꼭 써야 할 내용이 있다. 편지봉투에는 보내는 사람이 왼쪽 위에, 받는 사람이 오른쪽 아래에 작성돼야 하는데 이 형식, 규칙, 약속이 protocol이다. 이런 합의가 있기 때문에 주고받을 때 별 탈이 없다.

 

2. HTTP(Hyper Text Transfer Protocol)란?

HTTP의 특징 1. 텍스트 기반의 프로토콜

 

HTTP는 'Hyper Text Trnasfer Protocol'로 여기서 Protocol이 핵심이다. HTTP는 Text Transfer에 대한 규칙이다. text이기 때문에 단순하고 읽기 쉬운 특징을 갖고 있다. Hyper Text는 HTML이라 생각하고 넘어가자. 주황색 네모박스를 보면 요청과 응답이 HTTP 규칙을 지키고 있다. 내용은 이해하기 어렵지만, text로 읽을 수 있다. HTTP의 이 특징이 Human readable이다. 실제로 요청, 응답을 할 때 주황색 네모박스와 같은 text message를 주고받는다.

 

HTTP의 특징 2. stateless

 

HTTP의 특징 중 한 가지는 '상태를 유지하지 않는다.'이다. stateless라고 하며 상태가 없다는 뜻이다. 누구의 상태가 없다는 것일까? server는 클라이언트가 요청을 2번 보내도 같은 클라이언트인지 구분하지 못한다. HTTP는 상태를 저장하지 않기 때문에(요청한 클라이언트의 정보를 갖고 있지 않기 때문에) 똑같은 요청이면 앞서 보낸 요청과 뒤에 보낸 요청을 구분할 방법이 없다.

 

ℹ️ 이를 보완하기 위해 쿠기와 세션을 사용한다. 이 둘을 사용하면 클라이언트를 구분할 수 있다.

 

HTTP의 특징 3. 확장성

 

HTTP는 확장 가능하다. HTTP 응답 메시지를 보면 헤더, 바디가 있다. 헤더 영역의 한 줄 한 줄이 헤더이다. 헤더는 '헤더 이름:값⤶(줄 바꿈 문자열)'로 구성돼있다. 헤더이름은 대소문자 구분하지 않고, 공백은 무시된다. 서버와 클라이언트 사이에 약속이 돼있으면 확장할 수 있다.

 

3. HTTP 메시지

HTTP 응답 메시지는 business letter와 같다. 첫 번째, text기반이고 두 번째, 메시지의 정보가 담긴 헤더가 나오고 다음에 내용인 바디가 나온다.

 

 HTTP 메세지는 서로에게 요청 편지(헤더+바디)를 보내고, 응답 편지(헤더+바디)를 보내는 것이다.

 

브라우저에 URL을 입력하면, 브라우저가 자동으로 요청 메세지를 만들어 전송한다. 요청 메시지가 서버에 도착하면 서버는 받아서 응답 내용인 'Hello'를 브라우저에 띄운다.

 

4. HTTP 메세지 - 응답 메시지

1. 헤더

 

응답 메시지의 첫번 째 줄은 status line으로 요청이 어떻게 처리되었는지 알려준다. 번호 '200'은 상태 코드, 'OK'는 상태 코드의 설명이다. HTTP/1.1 protocol로 통신을 했고 요청에 대한 결과가 코드 '200'이다.

 

2xx번은 Success 성공했다는 뜻이다. 3xx번은 다른 URL로 요청하라는 말이고 연락을 했더니 다른 부서이니 번호를 주면서 이쪽으로 연락해보라는 말이다. 4xx, 5xx번은 둘다 Error이다. 유명한 404 Not Found는 클라이언트가 요청을 잘못 보내서 서버가 찾을 수 없다는 뜻이다. 5xx번은 클라이언트의 요청을 잘 받았지만 Server에서 처리하다 Error가 생겼다는 말이다. 1xx번은 HTTP/1.1부터 추가되었고 clinet, server 사이의 정보 교환목적으로 생겨났다. 잘 쓰지는 않는다.

 

⭐ 2xx, 3xx, 4xx, 5xx번 정도만 잘 알아두자.

 

 URL에 localhost/ch2/getYoil을 입력했을 때, 500번 Error가 발생한다. NumberFormatException예외가 발생했는데 처리하지 못해서 발생한 Error이다.

 

 year, month, day 입력을 받아야 하는데 값이 없을 경우를 대비하는 코드가 없다. 따라서 프로그램 실행 중 테스트를 철저히 해서 이런 오류가 없게 만들어야 한다.

 

2. 바디

 

헤더와 바디에는 빈 줄 하나가 있다. 헤더영역에 헤더는 한 줄이 아니라 N줄이고 각 line은 줄바꿈이 되어 있다. 헤더는 'header-text + ⤶(줄 바꿈 문자열)'이 하나의 단위이다. 헤더가 몇 line일지 모르기 때문에 빈 줄을 둬서 헤더와 바디를 구분한다. 바디에는 응답 내용이 온다. status line, 헤더, 바디를 합쳐서 Sever가 Client에게 전달하는 응답 메세지를 구성한다.

 

위 형식을 'HTTP 응답 메세지 format 형식'이라 한다. 이 형식으로 Client에게 전달해야 알아먹을 수 있다는 말이다.

 

⭐  빈 줄을 두는 이유는 헤더 line을 구분하는 것이 줄 바꿈 문자열인데 만약 빈 줄(=줄 바꿈 문자열)이 없으면 헤더가 더 있을 것이라 생각할 수 있다. 텍스트 없이 ⤶(줄 바꿈 문자열)이 있으면 헤더가 끝나는 지점이라 생각하면 쉽다.

 

5. HTTP 메세지 - 요청 메시지

GET, POST를 요청 메서드라 하고, 요청에 따라 메세지의 형태가 다르다. 요청 메세지도 응답 메세지의 형식과 비슷하다. 첫 줄에는 request line(응답 메세지에서는 status line), 헤더, 바디 순으로 온다.

 

GET은 서버에게 resource를 요청해서 읽어오는 메서드로 바디가 없다. 대신에 request line에 QueryString을 추가 정보로 입력할 수 있다. POST는 바디가 있어 GET요청의 QueryString이 바디에 들어간다. 바디에는 서버에 전송할 data를 담고 있다. GET이 read라면 POST는 write이다. GET은 단순히 server에 있는 resource를 가져오므로 읽기만 하는 반면 POST에는 글쓰기, 로그인 회원가입 파일 첨부 기능을 할 수 있다. 따라서 GET 요청은 서버에 줄 내용으로 URL의 QueryString으로 충분하지만 POST는 글쓰기 기능만 하더라도 data가 많기 때문에 내용이 바디에 들어가야 한다.

 

6. HTTP 메세지 - GET, POST

GET 메서드는 data를 read하기 위해 설계되었고, POST 메서드는 서버에 data를 입력하기 위해 만들어졌다. 

 

GET 메서드는 data를 담기위해 만들지 않았기 때문에 바디가 없어 대신 data를 URL에 담는다. QueryString으로 data를 전달해 용량이 작다. 크롬의 URL에는 대략 7천자 정도 들어간다. 반대로 게시판에 글을 쓰기 위해서 고안된 것이 POST 메서드이다. POST는 바디에 data를 담아 전송하기 때문에 용량에 제한이 없다.

 

GET은 URL에 data가 붙어있어 보안에 취약하지만 대체로 보여도 상관없는 data가 들어간다. 대신 data 공유에 유리하다. 다른 이에게 data 전달이 쉽다는 말이다. 친구에게 메신저로 제품 링크를 보냈을 때 상대방이 볼 수 있는 이유는 URL뒤에 제품 id가 QueryString으로 붙기 때문이다.

 

- 그닥 중요한 내용은 아님

POST는 상대적으로 보안에 유리하고 data 공유는 불리하다. 상대적으로 보안에 유리하다는 말은 POST로 전송했다고 보안에 절대적으로 안전하다는 말이 아니다. HTTP에 TLS Protocol을 적용하면 https:// 가 만들어진다. TLS는 암호화 Protocol이다. TLS는 SSL에서 발전한 모델이다. 아무튼 TLS없이 POST 방식을 사용하면 보안에 취약하다.

 

"http://localhost/ch2/getYoil? year=2021&month=10&day=1"입력하고, 브라우저 창에서 우클릭하고 검사를 클릭한다.

 

크롬의 개발자 도구에서 Network에 들어가 새로고침(F5, ctrl+R)을 하면, URL로 요청이 들어오고 Name의 요청 항목을 클릭하면 Headers 정보를 볼 수 있다.

 

General에는 요청과 응답의 공통헤더 부분이고 Request Method는 GET, Status Cod는 200으로 요청이 성공했다. Response Headers는 응답 헤더로 맨 첫 줄에는 status line, Request Headers는 요청 헤더로 request line이 맨 첫 줄에 적혀 있다.(보이지 않으면 View source를 클릭하자.)

 

 POST 요청은 바디에 <form> tag를 직접 작성해야 하는데 작성을 도와주는 확장 프로그램인 postman을 사용한다.

 

 postman에서 "http://localhost/ch2/getYoil"을 GET요청하게 되면 500 Error가 발생하게 된다. GET 요청은 data를 URL에 QueryString으로 요청해야 하는데  QueryString값을 입력하지 않을 경우를 대비한 코드가 없기 때문에 500 Error가 발생한다.

 

 URL params을 이용하면 QueryString을 자동으로 입력해 준다. 따라서 아래와 같이 결과물이 나온다.

 

  POST 요청은 year=2021&month=10&day=1 data가 url이 아니라 바디에 들어간다.