(2) - HTTP 알기

HTTP란?

HyperText(하이퍼링크를 통해 독자가 한 문서에서 다른 문서로 접근할 수 있는 텍스트) Transfer(교환) Protocol(규칙)의 줄임말이다. 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신규약이라는 의미이다.

웹브라우저(client)와 웹서버(server)즉, 서로 다른 컴퓨터 간에 컨텐츠를 교환하기 위한 규칙과 그 메세지가 HTTP이다.
여기서 Transfer Protocol이라는 말은 "웹 간에 어떠한 것에대해 요청하고, 그 응답을 받아야하는데 그 과정에서 어떤 방식으로 주고 받을지에 대한 규칙이 적힌 메세지"이다.

HTTP 기반 시스템의 구성요소

HTTP 각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 response라고 불리는 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있다. 
예를 들면 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다.

실제로 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들이 존재한다(라우터, 모뎀) 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP는 애플리케이션 계층의 최상위에 있다고 볼 수 있다.

Client(클라이언트): 사용자 에이전트
Client는 사용자를 대신하여 수행하는 모든 도구이다. 이 역할은 주로 브라우저에 의해 수행되는데 브라우저는 항상 요청을 보내는 개체이다. 예를 들어 웹페이지를 표시하기 위해, 브라우저는 페이지의 HTML문서를 가져오기 위한 요청을 전송한 뒤, 파일을 구문 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(이미지,비디오 등등)을 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다. 브라우저는 HTTP요청 내에서 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시하는 역할을 한다. 

Server(웹 서버)
통신 채널의 반대편에 클라이언트에 의한 요청에 대한 문서를 제공하는 서버

프록시
웹 브라우저와 서버 사이에서 수많은 컴퓨터와 머신이 HTTP 메세지를 이어받고 전달한다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시라고 한다. 프록시는 눈에 보이거나 그렇지 않을 수 도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있다.

• 캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))
• 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)
• 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
• 인증 (다양한 리소스에 대한 접근 제어)
• 로깅 (이력 정보를 저장)

 

HTTP의 특징

.1.비연결성(Connectionless)
클라이언트와 서버가 한 번 연결을 맺은 후에, 요청과 응답이 마무리되면 연결을 끊어버리는 성질

1)비연결성의 장점
HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었고, 만약 서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 된다. 따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있다.

2) 비연결성의 단점
서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을 거쳐야 하므로 연결/해제에 대한 오버헤드가 발생한다.

-> 여기서 connection 에 대한 정보와 keep-alive가 등장하게 된다
비연결성의 단점인 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성이 등장했다.
General Header의 Connection은 송신자가 연결에 대한 타임아웃과 요청 최대 개수를 어떻게 정했는지에 대해 알려준다. keep-alive는 단어 그대로 이 연결을 영속적으로 유지한다는 의미이다. 이 영속성이라는 것은 한 번 통신하여 접속이 이루어지면, 정의된 시간까지 접속이 없더라도 대기하는 구조이다. 즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것이다. 

이러한 방식이 왜 필요한 것일까?
만약에 연결이 유지되지 않는다면, 매번 socket(port)를 열어야하고 이는 비용적인 측면에서 비효율적인 구조이다. 해서 keep Alive Time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려있는 socket(port)에 전송하는 구조가 되고, socket을 열기 위한 비용을 절약할 수 있다. 

Keep-alive의 성능적 특징

A. 장점 : 커넥션을 맺고 끊는 데 작업이 없어졌기 때문에 시간이 단축된다는 것이다. 또한 서버와의 연결을 위한 자원도 절약할 수 있다.
b. 단점 : 바로 바쁜 서버환경에서 Keep Alive를 사용할 경우 요청마다 연결을 유지해야하기 때문에 프로세스의 수가 기하급수적으로 늘어나면 한 access의 MaxClient값을 초과하게 된다. 따라서 메모리를 많이 사용하기 되며 이는 곧 성능 저하의 원인이 된다. 즉 대량 접속 시 효율이 떨어지게 된다.

2.무상태(Stateless)

클라이언트와 서버의 모든 통신은 독립적이라는 의미로 이해하는 것이 적합하다.이 말인 즉슨, 한 번 로그인을 위한 통신을 했더라도 다음 통신에서는 이 로그인에 대해서 알지 못하므로,유저의 로그인에 대한 정보를 유지시킬 방법을 생각해야 한다. 이러한 해결책으로 크게 쿠키와 세션, JWT토큰이 있다. 

1)쿠키
HTTP는 이러한 문제점을 해결하기 위해 브라우저 단에서 쿠키라는 것을 저장하여 서버가 클라이언트를 식별할 수 있도록 한다.

2)세션
쿠키는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약하다. 이와 달리 세션은 브라우저가 아닌 서버단에서 사용자 정보를 저장하는 구조이다. 
그런데 세션 정보도 중간에 탈취당할 수 있기 때문에 보안에 완벽하다고 할 수 없다. 또한 세션을 사용하면 서버에 사용자 정보를 저장하므로, 서버의 메모리를 차지하게 되고, 만약 동시 접속자 수가 많은 서비스일 경우에는 서버 과부하의 원인이 된다. 

3)토큰을 사용하는 OAuth,JWT
쿠키와 세션의 문제점들을 보완하기 위해 토큰(Token)기반의 인증 방식이 도입되었다. 토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술. 그래서 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성이 높은 기술이라 할 수 있다. 대표적으로는 OAuth와 JWT가 있다. 

HTTP방식의 진화

1)HTTP 1.0

• status 코드 추가: 상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있게 되었다.
• 요청 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있게 되었다.
• 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었다(Content-Type 덕분에)
• 좁은 의미에서 공식적인 표준이 아니다.
• Method -> GET, POST, HEAD
  
  
  

2) HTTP 1.1 - 표준 프로토콜

• 커넥션이 재사용될 수 있게 하였다. 즉 connection : keep-alive 속성을 default로 두었다.
• 파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능하게 하였다.
• 청크된 응답 또한 지원된다. -> 동적인 컨텐츠를 위한 방식(전체의 큰 덩어리를 쪼개서 보내는 것이 chunk)
• 메서드에 OPTIONS, PUT, DELETE, TRACE 가 추가

-> HTTP 1.1 의 문제점

• 연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈가 존재
• HOL(Head Of Line) Blocking (특정 응답 지연)
• -> HTTP/1.1의 사양상의 제한으로 클라이언트의 리퀘스트의 순서와 서버의 응답순서는 동기화해야 됨
• RTT(Round Trip TIme) 증가 (양방향 지연)
• 헤더가 크다 (특히 쿠키 때문)-> 사용자가 방문한 웹페이지는 다수의 http 요청이 발생하게 되는데 이 경우 매 요청시 마다 중복된 헤더 값을 전송하게 되며 각 도메인에 설정된 쿠키 정보도 매 요청시 마다 헤더에 포함되어 전송
• -> http/1.1의 헤더에는 많은 메타 정보들이 저장되어 있음.

 

3) HTTP 2.0

• Multiplexed Streams (여러 요청을 동시 처리)
• HOL (Head Of Line) 미발생
• Stream Prioritization (요청 리소스간 의존관계를 설정)
• Header 정보를 HPACK으로 압축
• -> 중복되는 헤더값을 색인값으로 처리
• Client 요청 없이 리소스 Push
• HTTP 1.1과 호환
• 페이지 로딩 속도 향상