HTTP : 웹의 기초

1. HTTP 개관

리소스

• 웹 콘텐츠의 원천

• 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다

  미디어 타입

  • HTTP에서 데이터 타입을 구분하기 위해 사용
  • MIME 타입을 사용한다 (ex : text/html, image/jpeg ..)

  URI

  • Uniform Resource Identifier
  • 정보 리소스를 고유하게 식별하고 위치를 지정
  • URL
  • Uniform Resource Locator
  • 특정 서버의 한 리소스에 대한 구체적인 위치를 서술
  • URN
    • 콘텐츠를 이루는 한 리소스에 대해 그 리소스의 위치에 영향 받지 않는 유일무이한 이름

트랜잭션

• 요청 명령과 응답 결과로 구성

  메서드

  • 서버에게 어떤 동작이 취해져야 하는지 알려주는 것

  상태 코드

  • 클라이언트에게 응답 결과를 알려주는 세자리 숫자

메시지

• 시작줄, 헤더, 본문으로 구성

  

TCP 커넥션

TCP

• HTTP가 사용하는 전송 계층 프로토콜
• 오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않는 데이터 스트림을 보장

웹의 구성요소

• 프록시 : 클라이언트와 서버 사이에 위치한 HTTP 중개자
• 캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
• 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버
• 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프록시

2. URL과 리소스

<스킴>://<사용자 이름>:<비밀번호>@<호스트>:포트/<경로>;<파라미터>?<질의>#<프래그먼트>

• 스킴 : 리소스를 가져오기 위한 프로토콜
• 호스트 : 접근 하려는 리소스를 가지고 있는 인터넷상의 호스트 장비
• 포트 : 서버가 열어 놓은 네트워크 포트 (HTTP 기본 : 80)
• 사용자 이름 & 비밀번호 : 일부 프로토콜에서 필요한 정보
• 경로 : 리소스가 서버의 어디에 있는지 알려주는 정보
• 파라미터 : 프로토콜의 파라미터(?)(생소해서 추가 정보가 필요합니다...)
• 질의 : 요청 받을 리소스 형식의 범위를 좁히기 위해 사용하는 정보
• 프래그먼트 : 리소스의 특정 부분을 가리키기 위한 정보(서버에 전송되지 않고 클라이언트에서만 사용)

이스케이프 문자열

• URL은 기본적으로 US-ASCII 의 7비트로 나타낼 수 있는 문자만 사용해야함
• US-ASCII로 나타낼 수 없는 문자를 URL에 사용하기 위한 방법
• %문자로 시작해 나타냄

3. HTTP 메시지

• 인바운드 : client to server
• 아웃바운드 : server to client
• 업스트림 : 메시지의 송신자
• 다운스트림 : 메시지의 수신자
• 모든 메시지는 다운스트림 방향으로 흐른다

메시지 문법

• 요청 메시지

<메서드><요청URL><버전>
<헤더>
<엔터티 본문>

• 응답 메시지

<버전><상태 코드><사유 구절>
<헤더>
<엔터티 본문>

• 메서드 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
• 요청 URL : 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
• 버전 : 이 메시지에서 사용중인 HTTP의 버전
  • HTTP/<메이저>.<마이너> ex) HTTP/1.1
• 상태 코드 : 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자
• 사유 구절 : 상태코드를 설명해주는 문구로 실제 동작과는 무관
• 헤더 : 요청과 응답 메시지의 추가 정보
• 엔터티 본문 : 임의의 데이터 블록으로 있을수도 없을수도 있음

헤더

• 일반 헤더 : 요청과 응답 양쪽에 나타날 수 있음, 메시지에 대한 아주 기본적인 정보를 제공
• 요청 헤더 : 요청에 대한 부가 정보를 제공 ex) referer, cookie
• 응답 헤더 : 응답에 대한 부가 정보를 제공 ex) set-cookie
• Entity 헤더 : 본문 크기와 콘텐츠 혹은 리소스 그 자체를 서술 ex) Allow, Content-Length
• 확장 헤더 : 명세에 정의되지 않은 새로운 헤더

4. 커넥션 관리

HTTP 통신 과정

1. URL에서 호스트명을 추출
2. 호스트명에 대한 IP 주소를 검색
3. 포트번호를 추출
4. IP 주소와 포트 번호를 이용해서 TCP 커넥션을 생성
5. HTTP 요청을 보냄
6. HTTP 응답을 받음
7. 커넥션 종료

TCP

• IP 패킷이라 불리는 작은 조각을 이용해 데이터를 전송
• IP 패킷 내부에는 잘개 쪼개진 데이터 스트림인 세그먼트가 들어있음
• <발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트> 네가지 값으로 커넥션을 구분하고 생성

TCP의 성능 지연 요소

TCP 커넥션 핸드셰이크 지연

• 연결이 완료되면 연결이 제대로 되었는지 확인하는 패킷을 서버에서 보내고 클라이언트에서 응답함
• 간단한 TCP 요청이라면 이 과정 자체가 오버헤드

확인응답 지연

TCP의 패킷 전송 무결성 확인 체계

• TCP는 세그먼트를 받으면 확인 응답 패킷을 송신자에게 전송
• 이 확인 응답에 대한 응답을 받지 못하면 해당 세그먼트를 수신자는 폐기
• 송신자는 보낸 세그먼트에 대한 확인 응답 패킷을 받지 못하면 해당 세그먼트를 재전송

편승(piggyback)과 그로 인한 지연

• 응답 패킷이 작으므로, 다른 패킷에 묶어서 전송해서 네트워크를 효율적으로 이용하는 것이 편승
• 편승할 응답패킷을 기다리다가 존재 하지 않으면 별도 응답 패킷을 전송
• 이 응답패킷을 기다리는 시간이 지연 요소
• HTTP는 편승이 일어날 확률이 적음

TCP 느린 시작

• TCP 커넥션이 막 만들어졌을때는 속도 제한을 걸고, 시간이 지날수록 차차 제한을 해제함

네이글 알고리즘

• TCP 세그먼트는 플래그와 헤더를 기본적으로 포함해야 하므로 여러 작은 TCP 데이터를 하나로 합쳐서 전송하는 알고리즘
• 확인 응답 지연과 합쳐지면 더더욱 성능을 낮추는 원인

HTTP Connection 헤더 관리

• Connection 헤더에 들어 있는 헤더 필드명은 수신자가 응답을 보낼 때 포함되어서는 안됨

HTTP 커넥션 관리

병렬 커넥션

• 동시에 커넥션 여러개를 이용해 병렬로 내려받음
• 반드시 항상 더 빠르지는 않음(대역폭 이슈, 성능 이슈)
• 사용자에게 더 빠르게 느껴질 수 있음

지속 커넥션

• 처리가 완료되어도 커넥션을 유지하는 방법
• HTTP/1.1 에서는 기본적으로 활성화 되어있고 연결을 끊기 위해서는 Connection:close 헤더를 포함해서 전송

파이프라인 커넥션

• 요청을 파이프라이닝해서 전송
• POST 요청과 같은 비멱등(nonidempotent) 요청을 이 커넥션을 이용해서 보내면 안됨

커넥션 끊기

• 커넥션의 입출력을 모두 끊는 방법과 한 방향만 끊는 절반 끊기 방법이 있음
• 우아하게(?) 커넥션을 끊으려면 보통 출력 커넥션을 끊고 입력 커넥션을 주기적으로 검사하면서 끊는 방법을 사용