728x90
전체적인 흐름
구체적인 설명에 앞서 전체적인 흐름을 살펴보고 하나씩 파고 들어가 보겠다.
- 브라우저 실행
- URL 입력
- 브라우저가 URL을 조사 후 리퀘스트 메시지 생성
- DNS 서버에 IP 주소 조사 신청
- OS에 웹 서버로 송신해주라고 의뢰
- 웹 서버 수신
URL
URL이란?
URL(Uniform Resource Locator)는 일반적으로 브라우저의 주소창에 "http://"로 시작하는 주소라고 생각하면 된다. 하지만 사실 "http://"뿐만아니라 "ftp:", "file:", "mailto:" 등도 있다. 이러한 것들은 하나의 기능 또는 하나의 액세스 방법 또는 하나의 프로토콜 종류를 나타낸다.
예를 들어서 "ftp:" 는 파일을 다운로드/업로드하는 FTP(FIle Transfer Protocol)의 클라이언트 기능을 나타내고 FTP 서버에 액세스하는 FTP 프로토콜이라는 것을 나타낸다.
그렇다면 "http:"는 어떤 것을 나타낸 것일까?
"http:"는 웹 서버에 액세스하는 기능을 나타내고 웹 서버에 액세스하는 HTTP(HyperText Transfer Protocol)라는 프로토콜을 나타낸다.
그냥 프로토콜의 종류를 나타내는 것이라고 이해해도 무방할 것 같다.
또한 이렇게 웹 서버, FTP 서버와 같이 액세스하는 대상에 따라 URL을 쓰는 방법이 다르다. 예를 들어서 웹 서버, FTP 서버에 액세스하는 경우에는 서버의 도메인명이나 액세스하는 파일의 경로명 등을 URL에 포함시키지만 메일("mailto:")과 같은 경우에는 보내는 상대의 메일 주소를 URL에 포함시킨다.
URL 조사(해독)
위에서 전체적인 흐름을 보면 브라우저에 URL을 입력하고나면 URL을 조사한다고 되어있다.
URL은 다음과 같이 구성되어있다.
http: + // + 웹 서버명 + / + 디렉토리명 + / + ... + 파일명
이렇게만 보면 모르겠으니 한 개의 URL을 예로 들어 보겠다.
http://www.kjy043286.tistory.com/dir1/file1.html
이 URL을 위에 있는 URL 구조와 같이 분해하면 다음과 같다.
http: + // + www.kjy043286.tistory.com + / + dir1 + / + file1.html
그리고 해독을 해보면 "www.kjy043286.tistory.com"라는 웹 서버에 있는 "/dir1/file1.html"라는 경로의 파일에 액세스한다라는 의미로 이해할 수 있다.
다음과 같이 파일명을 생략하는 경우도 있다.
- http://www.kjy043286.tistory.com/dir1/
이 URL은 "dir1"라는 디렉토리명을 지정해주었지만 파일명은 생략했다. 이럴 때는 이처럼 파일명을 생략할 때를 대비하여 웹 서버에 미리 'index.html' 또는 'default.html'이라는 파일명을 설정해둔다. 그러면 웹 서버가 '/dir1/index.html' 또는 '/dir1/default.html'이라는 파일에 액세스한다.
- http://www.kjy043286.tistory.com/
이 URL은 "/"라는 디렉토리를 지정해준 것이다 따라서 "http://www.kjy043286.tistory.com/dir1/"와 같이 '/index.html' 또는 '/default.html'이라는 파일에 액세스하게 된다.
- http://www.kjy043286.tistory.com
이 URL은 경로를 아예 생략해버렸다. 이런 경우에는 웹 서버의 루트 디렉토리 아래에 있는 미리 설정된 파일명의 파일 'index.html' 또는 'default.html'을 액세스한다.
- http://www.kjy043286.tistory.com/thing
이 URL에서의 '/thing'은 파일로 봐야하는 것일까 디렉토리로 봐야하는 것일까? 당연히 모른다. 그렇기 때문에 웹 서버는 'thing'이라는 것이 파일로 존재하면 파일명으로 보고 디렉토리로 존재하면 디렉토리로 본다. (같은 이름을 가진 파일과 디렉토리를 둘 다 만들 수 없기 때문)
HTTP
HTTP이란?
HTTP는 클라이언트와 서버가 주고받는 메시지의 내용이나 순서를 정한 것이다. 먼저 클라이언트가 서버에 리퀘스트 메시지를 보낼 것이다. 이 때 메시지 안에 '무엇'을 '어떻게'할 것인지를 작성한다.
여기서 '무엇' = URI, '어떻게' = 메소드(method)라 한다.
- URI
우선 URI에 대해서 알 필요가 있을 것 같다.
- URI는 URL의 상위 개념으로서 URI가 URL을 포함하고 있다고 생각하면 된다.
- URI = Uniform Resource Identifier이고 URL = Uniform Resource Locator이다. 즉, URI는 자원을 식별하고 URL은 자원의 위치를 가리킨다.
이것만으로는 URI와 URL과의 차이를 잘 모르겠다. 예를 들어서"http://www.kjy043286.tistory.com/main"와 "http://www.kjy043286.tistory.com/main?id=HTML&page=12"가 있다면 URL은 "http://www.kjy043286.tistory.com/main"이고 URI는 "http://www.kjy043286.tistory.com/main?id=HTML&page=12"라고 할 수 있겠다.
더 알기 쉽게 비유하자면 URL은 "서울특별시 강남구", URI는 "서울특별시 강남구 테헤란로 152 강남파이낸스센터"라고 할 수 있을 것 같다. (구글코리아 주소를 예로 듬)
보통 페이지 데이터를 저장한 파일의 이름이나 CGI 프로그램(웹 애플리케이션)의 파일명을 URI로 쓴다고 한다.
- Method
메소드는 웹 서버에 어떤 동작을 하고 싶은지를 전달한다. 다음 링크에서 HTTP 메소드 부분을 보면 각 메소드별로 어떤 동작을 하는지 정리해놓았다.
HTTP 메소드
리퀘스트 메시지가 웹 서버에 도착하면 웹 서버는 메시지의 내용을 해독한다. 이후에 리퀘스트 메시지에 쓰여있는 요구대로 동작하고 결과 데이터를 응답 메시지에 저장한다. 응답 메시지의 맨 앞부분에는 결과의 상태를 알 수 있는 상태 코드가 있다. 정상적인 상태 코드가 나왔다면 헤더 파일과 페이지의 데이터가 이어지고 해당 응답 메시지를 클라이언트에 반송한다. 그러면 이것이 클라이언트에 도착하여 브라우저가 메시지 안에서 데이터를 추출하여 화면에 표시한다.
상태 코드에 대한 내용은 다음 링크에서 볼 수 있다.
HTTP 상태 코드
HTTP 리퀘스트 메시지
이제 HTTP의 기본 개념은 알았으니 브라우저가 URL을 조사한 다음 HTTP 리퀘스트 메시지를 만드는 것에 대해 알아보겠다.
HTTP 리퀘스트 메시지의 포맷은 다음과 같다.
- 리퀘스트 메시지
<메소드><공백><URI><공백><HTTP 버전> <필드명>:<필드값> . . . <공백 행> <메시지 본문>
리퀘스트 메시지의 첫 행을 "리퀘스트 라인"이라고 한다.
위 포맷을 보면 맨 처음에 메소드가 있다 메소드에는 위에서 설명했듯이 GET, POST 등이 있을 것이다.
그리고 다음에 URI이 있는데 예를 들어 메소드를 GET으로 사용했다면 지정한 URI의 해당 페이지를 표시해준다. URI는 보통 "/<디렉토리명>/..../<파일명>"과 같이 파일이나 프로그램의 경로명을 쓴다.
첫 행의 끝으로 메시지가 HTTP의 어느 버전의 사양을 바탕으로 쓴 것인지를 나타내기 위해 버전 번호를 작성한다.
두 번째 행 "<필드명>:<필드값>"부터 "<공백 행>" 전까지를 "메시지 헤더"라고 한다.
메시지 헤더에는 부가적인 자세한 정보를 작성하는 곳이다. 날짜, 클라이언트측이 취급하는 데이터의 종류, 언어, 압축 형식, 클라이언트나 서버의 소프트웨어 명칭과 버전, 데이터의 유효 기간이나 최종 변경 일시 등의 정보를 나타낼 수 있다. 또한 메시지 헤더에 쓰는 내용은 브라우저의 종류나 버전, 설정 등에 따라 달라지고, 몇 행에서 열 줄 이상의 메시지 헤더를 쓰는 경우가 많다.
메시지 헤더를 작성하였다면 이후에 "<공백 행>"을 넣고 그 뒤에 "<메시지 본문>"이라는 내용을 작성하게 된다. 여기서 이 "<공백 행>"이 메시지 헤더와 메시지 본문을 구분해준다.
메시지 본문은 말 그대로 메시지의 실제 내용을 의미한다. 만약 첫 번째 행에 GET 메소드를 사용한다고 되어 있다면 URI만으로 웹 서버가 무엇을 할지 판단 할 수 있으므로 메시지 본문에 쓰는 송신 데이터는 아무 것도 없다. 하지만 POST 메소드의 경우에는 폼에 입력한 데이터 등을 메시지 본문 부분에 쓴다.
HTTP 응답 메시지
리퀘스트 메시지를 웹 서버에 보내면 당연히 서버에서 응답 메시지가 돌아올 것이다.
응답 메시지의 포맷도 다음과 같다.
- 응답 메시지
<HTTP 버전><공백><스테이터스 코드><공백><응답 문구> <필드명>:<필드값> . . . <공백 행> <메시지 본문>
응답 메시지의 첫 행은 맨 처음 HTTP 버전을 넣고 그 다음 리퀘스트의 실행 결과를 나타내는 스테이터스(상태) 코드를 넣는다.
첫 행의 끝은 숫자로 쓰여있는 스테이터스 코드와는 달리 문장으로 실행 결과를 알려주는 응답 문구가 들어간다. 예를 들어서 "OK", "Not found"와 같은 것들을 말한다.
응답 메시지가 돌아오면 이후에 데이터를 추출하고 화면에 표시한다.
페이지가 텍스트로만 되어 있으면 해당 Content를 추출하여 화면에 표시하면 끝이지만 영상, 사진 등을 포함하고 있으면 달라진다.
해당 Content안에 영상, 사진이 포함되어 있다면 그 영상, 사진 파일을 나타내는 "태그"라는 녀석이 있게된다.
처음에 브라우저에서 웹 서버에 영상 또는 사진을 포함하는 파일을 읽는 리퀘스트 메시지를 송신했다고 해보자. 그러면 서버에서는 브라우저에 리퀘스트 메시지에 있는 파일의 내용을 되돌려줄 것이다. 되돌려받은 브라우저는 그 내용을 쭉 보다가 영상 또는 사진이 들어가는 부분에 "태그"라는 녀석이 있는 것을 발견하게 될 것 이다. 그러면 그 부분은 기억해두고 무시해버린다.
이후에 기억해두었던 태그에 쓰여있는 파일과 같이 웹 서버에 다시 해당 파일을 읽기위한 리퀘스트 메시지를 송신한다.
예를 들어 하나의 Content에 3개의 영상이 포함되어 있다면 Content 파일을 읽는 리퀘스트 1번과 영상 파일을 읽는 리퀘스트 3번으로 총 4번 리퀘스트 메시지를 웹 서버에 보낼 것이다. 왜냐하면 파일을 한 번에 한 개씩만 읽을 수 있기 때문이다.
- URI
728x90
'Network' 카테고리의 다른 글
[웹 브라우저의 동작] 3. DNS (0) | 2021.05.15 |
---|---|
[웹 브라우저의 동작] 2. IP (0) | 2021.05.14 |
HTTP 상태 코드 (0) | 2021.05.05 |
HTTP 메시지 (0) | 2021.05.04 |
HTTP 프로토콜의 구조 (0) | 2021.05.02 |