본문 바로가기

교양/네트워크

HTTP 완벽가이드 - 1장 HTTP 개관

Welcome to hell...

6개월 전에 산 책인데, 몇번을 읽다 포기 한 줄 모르겠다. 이번 기회에 정리하면서 완독하는 것을 목표로 한다.

 

1장 HTTP 개관

1장에서는 HTTP 를 전체적으로 가볍게 훑고 넘어 간다.

 

HTTP : 인터넷의 멀티미디어 배달 부

HTTP는 text부터 거희 대부분의 모든 미디어들을 전송 할 수 있다. 그리고 이것들을 웹 리소스라고 부른다.

 

MIME 타입 데이터 포멧 라벨

 

원래는 메일 전송에 사용됬던 건데 성능이 좋아 HTTP에서 채택되었다고 한다.

웹 서버는 모든 HTTP 객체를 MIME타입을 붙힘

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types

 

MIME 타입

MIME 타입이란 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘입니다: 웹에서 파일의 확장자는 별  의미가 없습니다. 그러므로, 각 문서와 함께 올바른 MIME 타입을 전송하도록, 서버가 정확히 설정하는 것이 중요합니다. 브라우저들은 리소스를 내려받았을 때 해야 할 기본 동작이 무엇인지를 결정하기 위해 대게 MIME 타입을 사용합니다.

developer.mozilla.org

쉽게 생각하면 확장자를 담아두는 객체라고 생각하면 된다.

헤더의 Content-Type에 위치한다. 

일반 javascript 파일
엑셀 파일

위의 예시를 통해서 각기 다른 MIME를 확인 할 수 있다.

 

 

URI

서버의 특정 리소스의 이름을 의미한다.

 

예를 들면 아래와 같다.

 

http://jiwon3346/image/smile.gif -> jiwon3346웹 서버의 이미지 리소스의 URI

 

이는 다음과 같은 의미를 가진다.

http 프로토콜로 jiwon3346 서버의 images/smile.gif를 가져와라

 

URL

URL은 URI 에 속해 있다.

URL은 특정 서버의 한 리소스에 대한 구체적이고 정확한 위치를 의미한다.

 

URL의 표준 표맷과 각각에 대한 용어는 다음과 같다.
http://jiwon3346/image/smile.gif

http: // => 스킴 (리소스에 접근하기 위해 사용되는 프로토콜)

jiwon3346 => 서버주소

image/smile.gif => 리소스

 

보다시피 URI와 같은 것을 볼 수 있다. 그래서 오늘 날엔 URL = URI로 봐도 무방하다.

 

URN

 

URN 역시 URI 에 속해 있다.

URN은 리소스를 찾을 때 그 리소스의 위치에 영향을 받지 않는 유일무이한 이름 역할을 의미하는데, 이는 어느 서버 어느 프로토콜을 지정할 필요 없이 이름만으로 접근 가능하나 현재는 실험 중인 상태고 널리 채택되지 않은 상태이다.

 

eift:hhpe32:0012 와 같이 고유한 이름을 가진 형태라고 한다.

 

*HTTP 메서드

GET PUT DELETE POST HEAD

 

*상태코드

 

 

트랜잭션

요청 명령과 응답 결과로 이루어진 사이클을 의미한다.

 

애플리케이션은 하나의 작업을 수행하기 위해 여러 HTTP트랜잭션을 수행함.

예로 HTML 빼대를 가져 오고, CSS 를 가져오고, 첨부된 이미지를 가져오고, JS를 가져오고 이런 식

결국 웹페이지에 첨부된 리소스들은 각각 별개의 HTTP 트랜잭션을 필요로 함

실제로 웹페이지에 접속하면 여러 응답과 요청이 각기 동작한다.

 

메시지

 

요청과 응답시 주고 받는 것이며, 요청 메세지와 응답 메시지로 나뉜다.

< 표준 구조 >

시작 줄

요청이라면 무엇을 해야하는지

응답이라면 무슨 일이 일어 났는지

예제에는 GET 요청 로컬리소스로 tools.html을 HTTP로 요청 했고

성공 상태코드와 사유구절(OK)가 있다.

 

헤더

시작 줄 다음에 0개 이상의 헤더 필드가 이어짐.

키와 값으로 구성되어 있다..

헤더는 빈줄로 끝난다.

응답에 MIME타입이 Content-type에 응답 본문길이가 Content-Length에 있따.

 

본문

데이터가 들어 갈 수 있는 메세지의 본문이다.

요청의 본문은 웹서버로 데이터를 실어 보낼때

응답의 본문은 클라이언트가 읽을 데이터이다.

문자열이며 구조적인 시작줄과 헤더와 달리 본문은 임의의 이진 데이터를 포함(다양한 멀티미디어) 할 수 있다.

 

 

TCP 커넥션

TCP 커넥션을 통해 한 곳에서 다른 곳으로 옮겨 간다.

 

TCP/IP

HTTP는 애플리케이션 계층 프로토콜이므로 네트워크 통신의 핵심적인 세부사항에 신경쓰지 않는다. (주고 받는 내용들만 신경쓴다.) 대신 TCP/IP가 그 역할을 한다.

 

네트워크 7 계층

 

위의 글을 중심으로 다시한번 네트워크 7계층을 정리하고 넘어 가자.

 

1,2 계층에서는 좀 더 하드웨어와 연관되어 있다. 랜카드를 연결하고 랜선을 연결하고, 각 기기들을 마운트 하여 IP를 받을 준비를 한다.

 

3계층인 네트워크에선 실제로 IP와 여러 네트워크에 대한 설정을 관리한다.

 

4계층인 전송층에서 실제로 연결과 전송 그자체와 관련된 작업을 한다. 

 

 5~7계층은 전송원리에 대해선 관심이 없다. 전송 데이터와 데이터를 이해하기 위한 약속에 관심이 있다.

 

TCP

전송 계층의 한 종류이고 네트워크 계층오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않는 데이터 스트림과 같은 특징을 가진다. ( 안정적이되 느리다.)

 

TCP/IP

TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜 집합, 하드웨어를 숨기고 어떤 종류의 컴퓨터나 네트워크등 신뢰성 있는 의사소통을 한다.

 

그리고 HTTP 클라이언트가 서버와 통신하기 위해서는 IP주소와 포트번호를 이용하여 TCP/IP 커넥션을 맺어야 함

 

실제로 웹 브라우저 연결의 기본적인 절차는 다음과 같다.

 

1. 웹브라우저는 서버의 URL에서 호스트 명을 추출

2. 호스트명에서 IP로 변환

3. URL에서 포트 번호 추출

4. IP로 TCP 커넥션을 맺음

5. HTTP요청을 보냄

6. HTTP 응답을 받음

7. 커넥션이 닫히고 응답받은 HTTP를 유저에게 보여줌.

 

프락시

클라이언트와 서버 사이에 위치한 HTTP 중개자이다. 웹보안 어플리케이션 통합, 성능 최적화에 사용

 

예제로는 클라이언트의 요청을 필터링 하여 보안을 하거나, 쿠키를 담아두어 클라이언트의 요청이 서버까지 가지 않고 프락시에서 일부 처리함으로써, 성능 최적화에 도움을 준다.

 

캐시

많이 찾는 웹페이즈를 클라이언트 가까이에 보관하는 HTTP 창고, 특별히 많이 찾는 문서의 사본을 저장해두는 특별한 HTTP 프락시 서버이다. 서버에 직접 가서 받지 않아도 되서 훨씬 빨리 문서를 받을 수 있어 성능에 좋다.

 

게이트웨이

다른 어플과 연결된 특별한 웹 서버로 다른 서버들의 중개자로 동작하는 특별한 서버이다. 주로 HTTP트래픽을 다른 프로토콜로 변환하기 위해 사용됨

 

예를 들어 HTTP/FTP 게이트 웨이는 HTTP요청을 받아 FTP 서버에 FTP로 요청을 한 후 FTP을 응답받아 HTTP 응답을 한다. 

 

터널

단순히 HTTP통신을 전달하기만 하는 특별한 프락시, 주로 HTTP 터널은 비 HTTP 데이터를 하나 이상의 HTTP연결을 통해 그대로 전송하기 위해 사용된다.

 

HTTP/SSL 터널은 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송하는 것이 예시이다.

 

에이전트

자동화된 HTTP 요청을 만드는 준 지능적 웹 클라이언트이다.

웹 로봇 같이 자동으로 HTTP트랜잭션을 일으키고 다니면서 정보를(크롤러도 여기에 속하는 것 같다) 모으는 클라이언트를 의미한다.