브라우저가 서버와 통신을 하는 과정 (1)

이 글은 성공과 실패를 결정하는 1%의 네트워크 원리를 내가 이해하기 쉽게, 번역 말투를 조금 없앤 글이다.

아래 내용은 챕터 1의 스토리 1에 해당한다.

 

이 과정의 출발점은 브라우저에서 URL을 입력하거나, 네이버 검색창에 검색을 하거나부터 시작이 된다.

URL? URL이 무엇일까? Uniform Resource Locator의 줄임말로 일반적으로 브라우저에서 봤을 때 http://로 시작을 한다.
http는 일종의 프로토콜로 개념은 아래에서 설명을 할 것이고, 프로토콜에 대해 간단하게 알아보자.

 

프로토콜은 어떤 상대와 통신을 할 때 이 통신을 어떻게 진행할지 규칙을 정한 것을 프로토콜이라 한다.

정말 쉽게 예를 들어서 설명을 해보자면 편의점에서 물건을 살 때, 살 물건을 캐셔에게 가져다 주면 

캐셔가 바코드를 찍고, 계산을 위해 카드를 주면, 카드를 다시 돌려 받아 물건을 가져간다. 이것도 일종의 프로토콜이다.
편의점에서 물건을 사기 위한 규칙.

 

규칙이다 보니 어떤 서버와 통신을 할지에 따라 다른 프로토콜을 쓴다.
웹 서버와 액세스 할 떄는 http 프로토콜을 사용하고,
파일을 다운로드/ 업로드 하는 서버와 접속을 할 때는 http 프로토콜 대신 ftp를 사용한다.
그 외에도 여러 프로토콜을 상황에 따라 쓴다.

 

근데 URL은 프로토콜로만 이루어진 것이 아니다. www로 시작하거나, 아무튼 어디로 접속할지에 대한 정보가 필요하다.

그것을 도메인명이라고 하며 이것은 접근을 하는 웹 서버를 지칭한다.

필요에 따라서 사용자명이나, 포트 번호, 파일 경로 또한 URL에 추가가 될 수 있다.

 

그럼 브라우저는 우리가 작성한 URL을 가지고 어떻게 웹 서버에 Access 할 수 있을까??

아래의 예시 URL을 통해 그것을 알아볼 것이다.

http://www.test.co.kr/dir1/test1.html

먼저, URL을 조금 더 이해하기 쉽게 해독을 하자면 아래와 같이 분리를 할 수 있다.

1. http
2. www.test.co.kr

3. /dir1/test1.html

1번 프로토콜을 사용해 2번 도메인명을 가진 웹 서버에 3번 경로를 가진 파일에 접근한다는 의미이다.

 

가만 생각해보면 네이버나 구글에 Access 할 때 위와 같은 형태로 URL을 작성해서 Access 하지 않는다.
3번 경로를 제외하고 프로토콜 + 도메인명의 조합으로 많이 작성을 할 것이다.

URL의 작성 방법에 따라서 해독을 하기 때문에, 3번을 생략하고도 Access 할 수 있다.

 

이쯤에서 http 프로토콜의 개념에 대해 궁금증이 생길 수도 있다.
간단한 개념으로 설명을 하자면 http 프로토콜은 클라이언트와 서버가 주고 받는 메세지의 내용이나
순서를 정한 것이다[시작]. 여기서 메시지를 리퀘스트 메시지라고 한다. 어렵게 생각하지 말고 요청 메시지라 생각하면 된다.

이 메시지에는 "무엇을", "어떻게 해서" 라는 내용이 적혀있다. 

무엇을에 해당하는 것을 URI라고 한다. 엥 URI는 또 뭐고 URL은 또 뭐지? 이것은 나중에 글로 따로 간단하게 작성할 생각이다.
여기서는 간단하게  URL처럼 액세스 대상에 대한 것을 작성하면서, URL을 포함하는 더 넓은 개념이라고 생각하고 넘어가자.

그리고 어떻게 해서에 해당하는 것을 메소드(Method)라고 한다.이 메소드를 통해서 웹 서버에 어떤 동작을 하고 싶은지 전달한다.

메소드에 대한 자세한 사항을 알고 싶다면 "HTTP 메소드의 종류"를 검색해보면 더 자세한 것들이 나오게 된다

 

클라가 보낸 리퀘스트 메시지가 웹 서버에 도착을 하면 웹 서버는 해당 메시지를 해독을 한다.

URI(무엇을), 메소드(어떻게), 를 해석해서 그 요구에 따라 동작 후 결과 데이터를 응답 메시지에 저장을 한다.

응답 메시지의 맨 앞 부분에는 웹 서버가 클라이언트의 리퀘스트 메시지를 잘 처리했는지 결과가 적혀있다.

그것을 스테이터스 코드라고 한다. 흔히 우리가 자주 보는 404 Not Found 같은 에러 코드를 뜻한다. 

엄청 다양한 에러 코드들이 있으니 궁금하면 검색을 해보자!

그리고 스테이터스 코드 뒤로 헤더 파일, 페이지의 데이터가 붙어 있다. 이 응답 메시지가 클라이언트에 도착을 하게 되면

브라우저가 메시지 안에서 데이터를 추출해 화면에 표시하면서 HTTP의 동작이 끝!이 나게 된다.
★ 강조된 시작과 끝을 잘 보도록 하자!

 

이 아래로는 앞에서 설명한 리퀘스트 메시지가 만들어지는 과정과 응답 메시지가 만들어지는 과정을 설명한다.

궁금하면 봐도 되고, 안궁금하면 안봐도 되는 내용 같다!

 

리퀘스트 메시지 만들기

리퀘스트 메시지의 첫번 째 행에 리퀘스트 라인이라는 것을 적는다.

리퀘스트 라인에는 메소드, URI, HTTP 버전 등이 작성된다. 이 행만 봐도 메시지가 어떤 내용인지 간략하게 파악이 가능하다.

메소드에는 메시지의 용도에 따라서 PUT, GET, POST, DELETE 등이 작성이 된다.

URI에는 URL을 포함하는 액세스 대상이 작성된다. HTTP버전은 말 그대로 사용하는 HTTP버전을 말한다.

이 다음 줄에는 메시지 헤더라는 것이 쓰인다. 한 행에 한 개의 헤더 필드에 대한 값이 적힌다. 이 헤더 필드에는
리퀘스트 메시지에 대한 부가적인 정보를 나타내며 리퀘스트 메시지에 따라 행 수는 달라진다. 마지막에는 공백 행이 작성된다.

공백 행 다음에는 메시지 본문이 쓰인다. 이 곳에는 클라이언트에서 서버에 송신할 데이터가 적힌다.

예를 들면 POST 메소드를 사용해 리퀘스트 메시지를 만들 때 이곳에는 폼에 작성한 데이터가 넣어진다!

 

응답 메시지 만들기

응답 메시지는 위 리퀘스트 메시지에서 아주 약간만 달라진다.

첫 번째 줄을 스테이터스 라인이라고 하며, HTTP 버전, 스테이터스 코드, 응답 문구[스테이터스 코드 설명]이 적힌다.

그 아래로는 리퀘스트 메시지와 동일하게 메시지 헤더가 작성된다. 

메시지 본문에는 리퀘스트 메시지와 다르게 서버에서 클라이언트의 요청에 따라 처리된 데이터가 들어간다.

이 메시지 본문은 바이너리 데이터로 취급을 한다.

 

만약 페이지를 로딩할 때 영상이 포함되어 있다면! 페이지 로딩 시 해당 부분은 제외시켜 놓고 나머지 부분을 먼저 로딩한다.

아니! 로딩할 때 그 부분이 영상인지 어떻게 알아? 그건 HTML 코드로 태그라는 것이 있기 때문에 알 수 있다.

그럼 공백은 어떻게 채우지? 다시 한번 웹 서버에 액세스 후 태그에 쓰여 있는 영상 파일을 서버에게 받아서 화면에 띄워준다.

아니! 그냥 리퀘스트 메시지 한 번 보낼 때 모든 데이터를 다 받으면 되는거 아냐? 왜 굳이 또 영상 파일을 받으려고 웹 서버에 액세스해?

리퀘스트 메시지에 쓰는 URI는 한 개만으로 결정, 즉 한 번에 한개 씩만 읽을 수 있기 때문에 파일을 따로 따로 읽어야 한다!