HTTP 동작 과정

Notice

Recent Posts

Recent Comments

Link

« 2024/11 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

Tags more

Archives

Today

Total

관리 메뉴

mm Home

HTTP 동작 과정 본문

개발/기타

HTTP 동작 과정

jess_m 2017. 10. 26. 16:41

예전에 공부했던 내용을 정리~

HTTP 동작 순서

일반적으로 표현하는 클라이언트는 브라우저가 될 것이고, 서버는 웹 서버 혹은 웹 어플리케이션 서버가 될 것이다.

1. 사용자가 웹 브라우저에 URL 주소 입력

2. DNS 서버에 웹 서버의 호스트 이름을 IP 주소로 변경 요청한다.

3. 웹 서버와 TCP 연결 시도.

- 3 way Handshake : 클라이언트 - 서버간 신뢰성있는 연결을 하기 위해 3번의 패킷 교환 과정이다.

SYN : 클라이언트가 서버로 임의로 생성한 시퀀스 번호를 전달한다

SYN ACK : 서버는 클라이언트에서 전달한 시퀀스를 +1 시켜서 전달한다 (서버의 패킷을 정상 수신했다는 신호)

ACK : 클라이언트가 서버에서 전달해준 시퀀스를 +1 시켜서 다시 전달함 (서버-클라 간 패킷 교환이 정상적으로 이루어졌다는 신호)

*SYN (synchronize sequence numbers)

*ACK (acknowledgment)

서버 사이드에서는 진행 과정에 따라 LISTEN -> SYN_RCV -> ESTABLISHED 로 변경된다. 종료되면 CLOSED (종료된다고해서 리소스를 바로 반환시키지 않는다.)

4. 서버에게 GET 명령을 전송한다.

예시)

GET /index.html HTTP/1.1 -> 요청문

Host : www.daum.net -> 헤더

Body : -> (Get 요청이기 때문에 바디가 없다)

5. 서버가 클라이언트에게 데이터(웹 문서)를 회신한다.

예시)

HTTP/1.1 200 OK -> 상태문

Date: Thu, 12 Feb 2009 06:29:38 GMT -> 헤더 시작

Server: Apache/1.3.29 (Unix) PHP/4.3.4RC3

X-Powered-By: PHP/4.3.4RC3

Transfer-Encoding: chunked

Content-Type: text/html -> 헤더 끝

<HTML> -> body

<HEAD>

</HEAD>

…….

…..생략….

6. 서버 - 클라이언트간 연결 해제

- 4 way Handshake : 서버와 클라이언트 양쪽다 연결이 종료시킨다는 메시지를 보낸다. (양쪽 다 각각이므로 4번의 패킷교환이 일어남)

Client -> Server : FIN

Server -> Client : ACK

SERVER -> Client : FIN

Client -> Server : ACK

* 시퀀스를 임의 생성하여 전달시키고 ACK로 +1 증가시킨 값을 받는 것은 3 way Handshake와 동일하다.

7. 웹 브라우저가 웹 문서를 출력한다.

Request와 Response 의 구조를 간단히 살펴보면 아래와 같다.

요청 메시지 구조

• 요청문

– 요청메소드

– URL

– HTTP 버전

• 헤더

• 바디

응답 메시지 구조

• 상태문

– HTTP 버전

– 상태코드

– 상태이름

• 헤더

• 바디

여기서 Keep-Alive에 대한 내용도 참고할 수 있다.

HTTP는 TCP 기반이기 때문에 신뢰성 있는 연결을 한다. 그 말은, 실제 Request가 이루어지기 전, 후로 연결을 시도하고 연결을 해제한다는 것이다. 매번 커넥션을 맺고 끊다보니 비용이 발생한다. CPU, 메모리와 같은 리소스도 잡아먹고.. 서버에서 포트(유한한 자원)도 열어야한다.

계속적인 요청이 있는 경우 TCP 연결을 맺어놓고, 데이터 송수신만 하면 효율적인 구조가 되지 않을까?

-> 그래서 HTTP/1.1 스펙부터 keep-alive 헤더가 추가되어 커넥션을 맺은체로 사용할 수 있다. (Connection: Keep-Alive)

-> 하지만 모든 클라이언트가 1번씩만 호출되는 경우라면, keep-alive 설정된 시간만큼 자원을 유지하고 있어야하므로 더 비효율적이 된다.

어플리케이션 앞 단에 프록시 서버가 있다면 프록시와 어플리케이션은 당연히 keep-alive 설정을 하는게 이로울 것이다.

HTTP에 알아본 김에.. HTTP 2.0 에 달라진 점은 무엇인지 보자.

이미 잘 정리된 자료가 있다 ㅋㅋ

Multiplexed Stream

- 한 커넥션으로 동시에 여러개의 메시지를 주고 받을 수 있음. (응답도 순서에 상관없이 받는다.)

- HTTP/1.1의 Keep-Alive, Pipelining 의 개선

Stream Prioritization

- 특정 자원의 수신이 늦어질 경우, 의존성있는 자원도 렌더링이 늦어지는 문제가 발생할 수 있다. 2.0에서 자원간 의존관계를 설정하여 해결할 수 있음.

Server Push