티스토리 뷰

Web

HTTP 프로토콜

nooblette 2021. 7. 21. 16:36
반응형

HTTP protocol

HTTP Protocol(Hyper Text Transfer Protocol) 인터넷상에서 데이터를 주고받기위한 프로토콜이며,

TCP/IP 위에서 작동하고, html문서, 이미지, 동영상, 오디오 등 여러 종류의 데이터를 주고 받을 수 있다.

 


 

특징

1. 서버 <-> 클라이언트 모델을 따른다.

https://madooei.github.io/cs421_sp20_homepage/api/

 

클라이언트는 클라이언트 소프트웨어(Chrome, Safari, Edge 등...)가 설치된 컴퓨터를 통해 URI를 이용해서 서버에 접속하여 요청을 보낸다 -> Request

서버는 서버 소프트웨어(Apache, nginx, IIS 등...)로 그 요청을 받아서 해석하고 응답을 한다  -> Response

 

위와 같은 요청/응답은 80번 포트를 통해 서비스한다.

 

2. Connectionless & Stateless

http는 불특정 다수를 대상으로 원할한 요청을 처리하기위해 서버와 연결하여 요청을하고

응답을 받으면 연결을 끊어버린다. 즉, 자원 하나에 대해서 단 하나의 연결을 만든다.

수십만명이 웹 서비스를 사용하더라도 접속 유지는 최소한이기때문에, 결과적으로 더 많은 사용자의 요청을 처리할수 있다.

-> Connectionless 

 

하지만 연결을 끊어버리므로, 클라이언트의 이전 상태를 알 수 없다. -> Stateless

로그인과 같은 경우 클라이언트의 이전 상태를 모른다면 서비스를 하는데 문제가 생기기때문에,

http는 쿠키를 이용해서 이 문제를 해결한다.

 

 

쿠키(Cookie) : 클라이언트와 서버의 정보를 담고있는 조각.

로그인을 예로 들자면, 클라이언트가 로그인에 성공하면,
서버는 로그인 정보를 자신의 데이터베이스에 저장하고 동일한 값을 cookie형태로 클라이언트에게 보낸다. 

첫 요청 시 :
클라이언트 로그인 성공 
then, 서버가 로그인정보를 자신의 DB에 저장 
(서버는 Cookie를 키로하는 값을 데이터베이스에 저장하는 방식으로 "Session" 을 유지한다)
then, return 쿠키 to 클라이언트 

두번째 요청 시 :
이때 클라이언트가 cookie를 서버에 보내는데, 
서버는 cookie 값으로 자신의 데이터베이스를 조회해서 로그인 여부를 확인할 수 있다. 

출처 : https://shlee0882.tistory.com/107

 

3. URI (Uniform Resource Identifiers)

1번특성에서 말했듯이, 

클라이언트는 클라이언트 소프트웨어(Chrome, Safari, Edge 등...)가 설치된 컴퓨터를 통해 URI를 이용해서 서버에 접속하여 요청을 보낸다.

 

HTTP 가 전송 프로토콜이라면 URI는 자원의 위치를 알려주기 위한 프로토콜이다.

WWW(world wide web) 에서 유저가 접근하고자하는 자원의 위치를 나타내기 위해 사용한다.

https://www.naver.com/index.php 는 URI의 예시이다.

https : 자원에 접근하기 위해서 https 프로토콜을 사용한다.
www.naver.com : 자원의 인터넷 상에서의 위치는 www.naver.com이다. 
DNS를 통해 도메인은 ip 주소로 변환되므로, ip 주소로 서버의 위치를 찾을 수 있다.
index.php : 요청할 자원의 이름이다.

출처 : https://shlee0882.tistory.com/107

 

4. Method

클라이언트가 한 요청의 종류를 서버에게 알려주기 위해 사용한다.

 

다음과 같은 메소드가 있다.

GET : 자원을 얻기 위해 사용(select)

POST : 자원을 추가하기 위해 사용(insert)

PUT : 자원을 업데이트 하기 위해 사용 (update)

DELETE : 자원을 삭제하기 위해 사용 (delete)

HEAD : http 헤더 정보만 요청, 해당 자원의 존재 여부 or 서버의 문제 여부를 알기위헤 사용

OPTIONS : 웹서버가 지원하는 메소드의 종류를 요청

TRACE : 클라이언트의 요청을 그대로 반환한다(echo)

 

보통 웹 서비스들은 GET과 POST만을 이용해서 개발한다. DELETE나 PUT등이 필요한 요청에도 GET과 POST를 사용하는데,

 

예를들어 게시판에서 특정 레코드를 삭제 할때도 GET 으로 표현한다.

각 용도에 맞는 메서드가 준비돼 있음에도 이렇게 사용하는 이유는

  1. GET과 POST만으로도 모든 종류의 요청을 표현 가능함.
  2. 편하게 개발하기 위함.
  3. 웹 브라우저로 DELETE, HEAD등을 보내는 form이 없기 때문.

 

Restful API 서버의 경우에는 GET, POST, DELETE, PUT을 명시적으로 구분한다.

자원의 위치 뿐만 아니라 자원에 할 일 까지 명시가능 하기때문에, Open API 서버를 만들기 위해서 널리 사용한다.

 

아래는 사용 예다.

 

5. 요청 데이터 포맷과 헤더(Header)

요청 데이터는 "HEADER"와 "BODY"로 구성된다.

헤더에는 요청과 요청 데이터에 대한 메타정보들이 들어있다. 다음은 헤더의 일반적인 모습이다.

1
2
3
4
5
6
7
8
9
1 GET /cgi-bin/http_trace.pl HTTP/1.1\r\n
2 ACCEPT_ENCODING: gzip,deflate,sdch\r\n
3 CONNECTION: keep-alive\r\n
4 ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
5 ACCEPT_CHARSET: windows-949,utf-8;q=0.7,*;q=0.3\r\n
6 USER_AGENT: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24\r\n
7 ACCEPT_LANGUAGE: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4\rn
8 HOST: www.joinc.co.kr\r\n
9 \r\n
cs

 

HTTP 헤더는 라인피드와 캐리지 리턴(/r/n)을 함께 사용한다. HTTP 헤더를 파싱할 때 주의해야 한다.

 

1 GET /cgi-bin/http_trace.pl HTTP/1.1\r\n

  • 요청 메소드 : 4번에서 설명한 GET, PUT, POST, OPTIONS 등의 요청 방식.
  • 요청 URI : 요청하는 자원의 위치.
  • http 버전 : 웹 브라우저가 사용하는 프로토콜의 버전.

 

6. 응답 헤더 포맷

응답 헤더포멧이다. 응답 헤더는 서버의 여러 상태 정보를 포함하기 때문에, 꽤 복잡해질 수 있다. 

wget을 이용하면 헤더 정보를 가져올 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
# wget -S http://www.test.co.krsdf
HTTP/1.1 200 OK\r\n
Date: Fri, 08 Jul 2011 00:59:41 GMT\r\n
Server: Apache/2.2.4 (Unix) PHP/5.2.0\r\n
X-Powered-By: PHP/5.2.0\r\n
Expires: Mon, 26 Jul 1997 05:00:00 GMT\r\n
Last-Modified: Fri, 08 Jul 2011 00:59:41 GMT\r\n
Cache-Control: no-store, no-cache, must-revalidate\r\n
Content-Length: 102\r\n
Keep-Alive: timeout=15, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html\r\n
\r\n
cs

 

  1. wget으로 헤더 정보를 출력했다.
  2. 프로토콜과 응답코드 : 반드시 첫줄에 와야 한다. 3개의 필드로 구성돼 있다.
    1. HTTP/1.1 : 응답 프로토콜과 버전
    2. 200 : 응답 코드
    3. OK : 응답 메시지. Not Found, Internal Server Error 등의 메시지다.
  3. 날짜
  4. 서버 프로그램및 스크립트 정보.
  5. 응답헤더에는 다양한 정보를 추가할 수가 있다. 어떤 정보를 추가할지는 사실 개발자 마음이다. HTTP 기반의 서버/클라이언트 제품을 만든다면, 헤더에 애플리케이션 정보를 추가해서 사용하면 된다.
  6. 컨텐츠의 마지막 수정일
  7. 캐쉬 제어 방식.
  8. 컨텐츠 길이.
  9. Keep Alive기능 설정

 

6-1 응답코드.

 

2XX 성공

코드번호 설명 비고
200 성공 서버가 요청을 제대로 처리함.

 

4XX 요청 오류

코드번호 설명 비고
400 잘못된 요청 헤더 포맷이 http 규약에 맞지 않는 경우
403 금지 서버가 요청을 거부함
404 찾을 수 없음 요청한 자원이 서버에 존재하지 않음

 

7. Keep Alive

http 버전 1.1 이상 부터는 Keep Alive 기능을 지원한다.

앞서 설명했듯이, http는 하나의 자원에 대해 하나의 연결만 갖도록 connectionless 하게 설계되어있다고 했다.

 

요즘 웹 서비스의 경우 간단한 페이지라고 해도 수십개의 데이터가 있기 마련인데,

이 간단한 페이지를 표시하기위해 connectionless하게 연결을 맺고 끊는 과정을 수십번 반복한다면 비효율적일 것이다. 

(연결을 맺고 끊는것 갖체가 TCP 통신에서 가장 많은 비용이 소비되는 작업이다.)

 

예를들어, 웹 페이지로부터 html문서의 image, css, js파일을 다운로드 받을때 Keep-Alive 설정이 없다면

다음과 같은 과정을 거칠 것이다.

  1. 웹 서버에 연결 -> html 문서를 다운로드 받음 -> 웹 서버 연결 해제
  2. 웹 서버에 연결 -> 첫번째 이미지 다운로드 -> 웹 서버 연결 해제
  3. 웹 서버에 연결 -> 두번째 이미지 다운로드 -> 웹 서버 연결 해제
  4. 계속 진행...

간단한 페이지를 표시하기위해 필요한 파일을 다운로드 받는데, 연결을 계속 설정하고 해제하고 다시 설정하고 해제하는 과정을 수십번 반복하므로 비효율적이다.

 

이때 keep alive 설정을 하면, 지정된 시간동안 연결을 끊지않고 지속적으로 유지하여 요청을 보낼 수 있다.

  1. 웹 서버에 연결 -> html 문서를 다운로드 받음 -> 필요한 파일 다운로드 -> 모든 문서를 다운로드 받으면 연결 해제

Keep-Alive: timeout=15, max=100\r\n

 

이 말은 15초간 연결을 유지하고, 이러한 연결은 최대 100개까지 허용한다는 뜻이다.

Keep-Alive 설정을 하면 하나의 연결에 대해서는 효율적일수도 있지만,

한 자원에 대한 연결 자체가 길어지기때문에 동시간대 연결이 늘어난다.

운영체제에서 연결을 유한한 자원이기 때문에 연결을 다 소모해버리면 서버는 더이상 요청을 받을 수 없다.

이러한 이유로 max로 Keep-Alive 연결을 제한한다.


출처 : https://shlee0882.tistory.com/107

 

HTTP 프로토콜이란?

1. HTTP 프로토콜이란? HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다. 애플리케이션 레벨의 프로토콜로 TCP/IP위에서 작동한다.

shlee0882.tistory.com

출처 : https://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP

 

HTTP 프로토콜

scapy를 이용한 디버깅

www.joinc.co.kr

출처 : https://madooei.github.io/cs421_sp20_homepage/api/

 

RESTful API - OOSE

Separation of Client and Server We have stablished that our interest lies in software solutions that conform to the Client-Server architecture. A common practice to separate the Client and Server is Representational State Transfer, or REST architecture sty

madooei.github.io

 

반응형

'Web' 카테고리의 다른 글

웹 브라우저의 기본 원리  (0) 2021.07.26
URL과 URI의 차이  (0) 2021.07.26
[Django] MVC 패턴과 MTV 패턴  (0) 2021.07.14
MVC 패턴과 데이터 접근  (0) 2021.07.14
Web Service - MVC 패턴  (0) 2021.07.14
Comments