HTTP 완벽 가이드(1)

HTTP 완벽 가이드의 1. HTTP: 웹의 기초를 읽고 정리한 내용입니다.

2장: URL과 리소스

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷사의 수섭억 개의 리소스를 찾고 사용하며 공유할 수 있다.

URI는 URL과 URN으로 이루어져있다. URN은 현재 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별하고, URL은 리소스가 어디 있는지 설명해서 리소스를 식별한다. URN은 유일무이한 이름 역할을 한다. 즉 리소스를 다른 곳으로 옮기더라도 동일한 URN으로 사용이 가능하다. 하지만 URN은 아직 채택되지 않아 접할 기회가 많지 않다.

URL 구조

• 스킴(프로토콜): 리소스에 어떻게 접근하는지 알려준다.
• 도메인: 서버의 위치. 웹 클라이언트의 리소스가 어디에 호스팅 되어 있는지 알려준다.
• 포트: 리소스를 호스팅하는 서버가 열어놓은 포트번호. 많은 스킴이 기본 포트를 가지고 있다.
• 리소스 경로: 요청받은 리소스가 무엇인지 알려준다.
• 파라미터: 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터들을 받는다. 이름/값 쌍의 리스트로 이루어진다.
  • 질의 문자열(Query String): 요청받을 리소스 형식의 범위를 좁히기 위해서 사용할 수 있다. 대부분 ‘&’로 나뉜 ‘이름=값’ 쌍 형식의 질의 문자열을 사용한다.
• 프래그먼트(앵커): 리소스의 특정 부분을 가리킬 수 있도록 프래그먼트 컴포넌트를 제공한다.

안전하지 않은 문자

이스케이프라는 기능으로 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있다. 이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 하여 이동성과 완성도를 높인다.

안전하지 않은 문자를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾼다.

입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다

3장: HTTP 메시지

메시지의 흐름

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메시지가 서버로 향하는 것은 인바운드이고, 모든 처리가 끝난 뒤에 사용자에게 돌아오는 것은 아웃바운드이다.

모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

메시지의 구조

HTTP 메시지는 시작줄, 헤더, 본문 세 부분으로 이루어진다. 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이며, 본문은 데이터 덩어리이다.

시작줄

요청 메시지의 시작줄은 무엇을 해야하는지 말해주고, 응답 메시지의 시작줄은 무슨 일이 있었는지 말해준다.

요청줄에는 메서드와 그 동작에 대한 대상을 지칭하는 URL이 있다. 또한 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전도 포함한다.

응답줄에는 응답 메시지에서 쓰인 HTTP 버전, 숫자로 된 상태고드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있다.

헤더

헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. Content-length, ContentType 등이 들어간다.

엔티티 본문

HTTP 메시지의 화물이다. 이것을 수송하도록 HTTP가 설계된 것이다. 여러 종류의 데이터를 실어 나를 수 있다.

더 자세한 내용은 아래 링크에서 확인 가능하다

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers

4장: 커넥션 관리

TCP 커넥션

TCP 커넥션은 인터넷을 안정적으로 연결해준다. TCP는 HTTP에게 신뢰할 만한 통신 방식을 제공한다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확하게 전달된다.

TCP는 IP 패킷(IP 데이터그램)이라고 불리는 작은 조각을 통해 데이터를 전송한다. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다.

컴퓨터는 TCP 커넥션을 여러개 가지고 있다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지한다. TCP 커넥션은 발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트 네 가지 값으로 식별한다. 이 네 가지 커넥션 구성요소를 모두 똑같이 가리키고 있는 커넥션은 있을 수 없다.

TCP 소켓프로그래밍

운영체제에서TCP 커넥션의 생성과 관련된 여러 기능을 제공한다. 소켓 API를 사용하면 종단 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다. TCP API는, 기본적인 네트워크 프로토콜의 핸드셰이킹, TCP 데이터 스트림과 IP 패킷 간의 분할 및 재조립에 대한 모든 세부사항을 숨긴다.

TCP의 성능에 대한 고려

HTTP는 TCP 바로 위에 있는 계층이기 때문에 HTTP 트랙잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다. 클라이언트 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

지속 커넥션

HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 오늘날 많은 웹 애플리케이션은 적은 수의 병렬 커넥션만을 맺고 그것을 유지한다.

keep-alive

keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection: Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 다만 이 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다.

HTTP/1.1의 지속 커넥션

HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있다. 응답에 Connection: close 헤더가 없으면 응답 후에도 커넥션을 계속 유지하는 것으로 추정한다.