이 포스팅은 '성공과 실패를 결정하는 1%의 네트워크 원리' 책을 기반으로 작성되었습니다.
1장 웹 브라우저는 어떻게 동작하는가
Outline
1. HTTP Request 메시지를 작성한다.
URL을 결정된 규칙에 따라 분석하고 그 의미에 따라 리퀘스트 메시지를 만든다.
=> 메시지의 정체인 HTTP 프로토콜과 그 구조에 대해서 알아본다.
2. 웹 서버의 IP Address를 DNS 서버에 조회한다.
DNS 서버에 접근하여 메시지를 넘기는 상대의 IP Address를 요청한다.
=> 넘겨받은 메시지에는 URL이 있고 여기엔 도메인 명이 존재한다. 이 도메인 명을 기준으로 IP Address를 조회한다.
3. 전 세계의 DNS 서버가 연대한다.
수 만대의 DNS 서버가 어떠한 방법으로 연대를 하여 해당 IP 주소를 알려준다.
=> ‘DNS 서버들이 어떻게 연대하는가’에 대해 알아본다.
4. 프로토콜 스택에 메시지 송신을 의로한다.
알게 된 IP Address를 OS에 알려주면서 메시지 전달을 의뢰한다.
=> ‘어떻게 의뢰하는가’에 대한 부분으로 세밀한 규칙이 존재하여 그 규칙을 따라야 한다.
1장 첫번째. HTTP Request 메시지를 작성한다.
1. 브라우저는 먼저 URL을 해독한다!
URL(Uniform Resource Locator)이란?
우리가 자주 사용하는 http: 로 시작하는 것을 url이라고 한다. 이 뿐만 아니라 file:로 시작하는 url, mailto: 로 시작하는 url 등 여러 가지 url이 존재한다. http: 는 브라우저가 웹 서버에 액세스하는 클라이언트로 사용되는 경우의 url이다. 즉, 브라우저는 웹 서버 액세스 용 클라이언트 역할 뿐만 아니라 파일을 다운/업로드 하는 FTP의 클라이언트 기능이나 메일 클라이언트의 기능도 갖고 있는 복합적인 클라이언트 소프트웨어 인 것이다. 모든 URL은 http: 또는 ftp: 등 특정 문자열로 시작한다. 즉, 맨 앞에 있는 문자열 부분에 '액세스 하는 방법'을 명시한다. 이 액세스하는 방법을 프로토콜이라고 보면 된다. URL들은 이 프로토콜에 따라 어떻게 작성해야하는지 결정된다.
URL 분해하기
Example> http://www.asfirstalways.tistory.com/256
http: == 사용하는 프로토콜을 의미
// == 이어지는 문자열이 서버의 이름을 나타냄
www.asfirstalways.tistory.com == 웹 서버 명
/256 == 데이터 출처의 경로명
데이터 출처의 경로명을 생략할 수도 있다. 이 경우에는 서버측에서 설정해둔 파일 명으로 접손된다. 보통 index.html로 설정되어 있어 www.asfirstalways.tistory.com 으로 접속하면 www.asfirstalways.tistory.com/index.html 에 액세스 하게 된다. URL을 해독하면 어디에 액세스해야 하는지가 판명된다. http: 로 시작하는 URL의 경우에는 HTTP 프로토콜을 사용하여 웹 서버에 액세스하게 된다.
2. HTTP 프로토콜에 대해서
HTTP 프로토콜은 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 일종의 약속이라고 할 수 있다. 클라이언트에서 서버에게 보내는 메시지 안에는 ‘무엇을’, ‘어떻게’ 에 대한 내용이 담겨져 있다.
‘무엇을’에 해당하는 것을 URI(Uniform Resource Identifier)라고 한다. 이 URI는 액세스 대상을 통칭하는 말로, URL 그 자체가 URI가 될 수 있으며, 보통 페이지 데이터를 저장한 파일 이름(index.html) 또는 CGI 프로그램 파일명이 URI로 사용된다.
‘어떻게’에 해당하는 것을 메소드라 하며, 이 메소드를 통해 어떤 동작을 하고 싶은지를 전달한다. 이 동작에는 'URI에 해당하는 것을 읽겠다' 또는 URI에 해당하는 내용을 '서버에 전송하겠다’ 등의 동작이 있다.
‘무엇을’, ‘어떻게’ 말고 추가적으로 보낼 정보가 있을 수도 있다. 그 때는 헤더 파일을 이용한다. HTTP 메시지에는 보충 정보를 나타내는 헤더 파일을 포함하고 있다.
cf> CGI(Common Gateway Interface)
CGI란 웹 서버 소프트웨어에서 프로그램을 호출할 때의 규칙을 정한 것이고, 이 CGI 규칙에 맞게 움직이는 프로그램을 CGI 프로그램이라고 한다.
리퀘스트 메시지가 웹 서버에 도착하면 웹 서버는 메시지 내용을 해독한다. ‘무엇을’, ‘어떻게’에 대한 동작을 하고, 결과 데이터를 응답 메시지에 저장한다. 이 응답 메시지의 맨 앞 부분에는 실행결과가 정상 종료되었는지 또는 이상이 발생했는지를 나타내는 Status Code가 들어있다. 이 status code 뒤로 헤더 파일과 데이터가 이어진다. 이러한 구조의 응답 메시지가 클라이언트에게 반송되며 브라우저는 응답 메시지를 받아 화면에 표시하면서 HTTP 동작이 끝난다.
3. HTTP Request Message 를 만들자!
다시 돌아가서, HTTP 프로토콜을 사용하여 웹 서버에 액세스 하기 위해서는 HTTP 리퀘스트 메시지를 만들어야 한다. HTTP 메시지를 쓰는 포맷은 정해져있으므로, 이 포맷에 맞게 리퀘스트 메시지를 만들게 된다.
* 리퀘스트 메시지 구조
<메소드><공백><URI><공백><HTTP버전> — 리퀘스트라인
<필드명>:<필드값> — 메시지 헤더
...
<공백 행>
<메시지 본문>
http://sabercomlogica.com/en/ebook/application-layer-http-protocol-connections/
리퀘스트 메시지를 보내면 웹 서버에서 응답 메시지가 되돌아 온다.
* 응답 메시지 구조
<HTTP버전><공백><Status Code><공백><응답 문구> — 스테이터스 라인
<필드명>:<필드값> — 메시지 헤더
...
<공백 행>
<메시지 본문>
http://sabercomlogica.com/en/ebook/application-layer-http-protocol-connections/
리퀘스트 메시지에 쓰는 URI는 한 개만으로 결정되어 있다. 즉 파일을 한 번에 한 개씩만 읽을 수 있다. 따라서 복수의 파일을 읽을 때는 웹 서버에 별도의 리퀘스트 메시지를 보내게 된다.
+GET과 POST의 차이
HTTP 메시지의 구조면에서 보면, GET으로 전달되는 정보는 리퀘스트 라인에 쿼리 스트링으로 입력되어 전달되고 POST로 전달되는 정보는 HTTP 메시지 본문에 포함되어 전달된다.
1장 첫번째 end
'Dev.Basic > 네트워크' 카테고리의 다른 글
[2장] 1. TCP/IP - 소켓을 작성하고 서버에 접속한다. (0) | 2016.11.10 |
---|---|
[1장] 4. 프로토콜 스택에 메시지 송신을 의뢰한다. (0) | 2016.11.09 |
[1장] 3. 전 세계의 DNS 서버가 연대한다 (0) | 2016.11.07 |
[1장] 2. 웹 서버의 IP 주소를 DNS 서버에 조회한다. (0) | 2016.11.06 |
[Intro] 브라우저부터 서버까지 네트워크의 큰 흐름 (2) | 2016.10.08 |