이현수

이현수

꾸준히 공부하는 컴퓨터공학과 학생입니다.

[네트워크] 웹사이트 흐름

3 분 소요

웹사이트

웹사이트란 웹서버 애플리케이션이 공개하는 다양한 웹페이지의 집합.

웹사이트를 볼 때, 웹브라우저와 웹서버 애플리케이션 사이의 웹페이지 파일 전송이 한번으로 끝나는 것이 아니다. 필요하면 여러번 파일 전송을 반복. 웹페이지 파일 전송에 이용하는 TCP/IP의 애플리케이션계층 프로토콜은 HTTP이다.

웹페이지 - HTML, CSS

웹페이지는 html 파일로 만든다.

스타일 시트(css)를 이용해 문서의 레이아웃이나 문자의 포트와 색 등 웹페이지의 디자인을 정의한다.

웹사이트 주소

웹사이트 주소는 주로 http://로 시작되는 문자열로, URL이라고 불린다.

맨앞의 http는 스킴이라고 해서, 웹브라우저나 웹서버의 데이터에 접속하기 위한 프로토콜을 나타낸다. 보통은 http이지만 ftp 등을 이용하기도 한다. 콜론 : 뒤에는 파일이 있는 장소를 나타내고, //는 그 뒤로 이어지는 부분이 호스트명임을 나타낸다. 웹서버에 접속할 때 호스트명에서 ip주소로 변환하는 DNS의 이름해석이 필요하다.

호스트명 뒤에는 포트번호가 이어지지만 대부분 생략한다. 생략한 경우 지정된 스킴에서 프로토콜의 웰노운 포트를 사용한다.

웹사이트 파일 요청

웹사이트를 구성하는 html파일을 전송하기 위해 http를 이용한다. http는 html 파일뿐만 아니라 다양한 종류의 파일을 전송하는 범용적인 프로토콜이다. jpeg이나 png 등의 이미지 파일은 물론이고, pdf나 워드, 엑셀 등의 문서 파일도 전송할 수 있다.

http 파일 전송은 http 리퀘스트와 http 리스폰스를 주고받으면서 이루어진다.

http는 트랜스포트층의 프로토콜로서 tcp를 이용하므로, http 통신을 하기전에 tcp 커넥션을 맺는다.

Http request

http request는 리퀘스트 라인, 메시지 헤더, 엔티티 바디의 세 부분으로 나뉜다. 메시지 헤더와 엔티티 바디 사이에는 공백 라인이 없다.

리퀘스트 라인은 http request 첫번째 줄로, 웹서버에 대한 실제 처리 요청을 전달한다. 리퀘스트 라인은 다시 메소드, url, 버전으로 구성된다. 메소드는 서버에 대한 요청을 나타내는 것으로 get, post 등이 있다. get 메소드가 가장 자주 사용된다.

메시지 헤더는 요청 라인에 이어지는 여러줄의 텍스트이다. 여기에는 웹브라우저의 종류와 버전, 대응하는 데이터 형식 등의 정보를 기술한다.

메시지 헤더 다음은 공백 라인으로 구분하고, 그 뒤로 엔티티 바디가 이어진다. 엔티티 바디는 post 메소드로 웹브라우저에 데이터를 보낼 때 사용한다.

Http response

http request에 대한 응답으로 http response를 반환한다.

http response는 리스폰스 라인, 메시지 헤더, 엔티티 바디로 구성된다.

리스폰스 라인은 버전, 상태코드, 설명문으로 나뉜다. 버전은 리퀘스트와 마찬가지로 http의 버전을 나타내며, 상태코드는 리퀘스트에 대한 웹서버 애플리케이션 처리 결과를 나타내는 3자리로된 숫자이다. 상태코드는 맨 앞자리에서 대략적인 의미가 정해진다.

설명문은 상태코드의 의미를 간단히 보여주는 텍스트이다. 웹서버 애플리케이션이 반환하는 상태 코드에서 가장 많은 것은 200이다. 200은 요청이 정상적으로 처리됐음을 의미한다. 404는 url을 잘못 입력하거나, 웹페이지가 삭제될 때 나타난다.

메시지 헤더는 웹서버 애플리케이션이 더 자세한 정보를 웹브라우저에 전달하기 위해 이용한다. 데이터형식이나 갱신 날짜 등이 기술된다.

그 뒤로 구분을 위한 공백 라인이 있고, 공백 라인 뒤에 엔티티 바디가 이어진다. 엔티티 바디에는 웹브라우저에 돌려보낼 데이터가 들어간다. 웹브라우저에 돌려보내는 데이터는 주로 html 파일이다.

쿠키

http 쿠키는 웹서버 애플리케이션이 웹브라우저에 특정 정보를 저장해 두는 기술이다. 웹서버 애플리케이션은 웹브라우저의 요청에 대한 http 리스폰스에 쿠키를 포함해 보낸다. 쿠키 정보는 http 헤더에 포함된다. 웹브라우저가 쿠키를 받을 수 있게 설정되어 있으면 ,수신한 쿠키를 저장한다.

쿠키를 이용함으로써, 웹서버는 사용자의 로그인 정보나 사이트 내 웹사이트 열람 이력을 관리할 수 있다. 접속한 사용자에게 맞는 웹페이지 내용을 개인화할 수도 있다.

프록시 서버

웹페이지를 열람할 때 웹브라우저와 웹서버 애플리케이션은 서로 통신을 한다. 이대 그 사이에 프록시 서버를 거치는 경우가 있다.

프록시 서버는 웹사이트 접속을 대행하는 서버이다.

  1. 클라이언트 pc의 웹브라우저에서 url을 입력하면, 프록시 서버로 http 리퀘스트를 보낸다.
  2. 프록시 서버에서 url로 지정된 웹서버에 http request를 보낸다.
  3. 웹서버에서 프록시 서버로 http 리스폰스를 보낸다.
  4. 프록시 서버에서 클라이언트 pc의 웹브라우저로 http response를 보낸다.

클라이언트 pc의 웹브라우저에서 프록시 서버에 접속할 때에 tcp 포트번호 8080을 사용하는 경우가 많다.

웹브라우저의 사용성 증가

오늘날 웹브라우저는 단순히 웹사이트만 보는 애플리케이션이 아니다. 웹브라우저를 유저 인터페이스로 이용하는 애플리케이션을 웹 애플리케이션이라고 한다.

예전에는 기업이 사내에서 이용할 업무 애플리케이션을 개발해서 이용하는 것이 일반적이었지만, 업무용 애플리케이션은 사용자가 접하는 화면 레이아웃이나 입력 파라미터 처리 등도 모두 만들어야 한다. 또 개발한 업무 애플리케이션은 클라이언트 pc에 설치하고 최신전을 유지해야 한다.

반면, 웹 애플리케이션은 브라우저를 유저 인터페이스로 이용해 클라이언트 pc에서 전용 애플리케이션을 개발해 설치해둘 필요가 없다. 웹브라우저만 설치되어있고, 인터넷만 연결되면 된다.

처리 자체는 웹서버가 아니라 별도 애플리케이션 서버를 이용하기도 한다. 애플리케이션 서버는 다시 데이터베이스 서버와 연계하는 경우도 있다.

웹사이트 흐름

  1. 웹 브라우저에 url을 입력. 혹은 웹페이지 링크 클릭

  2. tcp/ip는 반드시 ip 주소를 지정해야 한다. url에 포함된 웹서버의 호스트명을 DNS 서버에 질의해 웹서버의 ip주소를 해석.

  3. DNS 서버에 질의할 때 이더넷의 MAC주소를 구하기 위해 ARP도 실행.

  4. 웹서버의 ip주소를 알면, 그 ip주소를 지정해 웹브라우저와 웹서버 애플리케이션 간에 TCP 커넥션을 맺는다.

  5. 웹브라우저와 웹서버 애플리케이션 간의 TCP 커넥션을 확립하고 나서부터, HTTP 리퀘스트와 HTTP 리스폰스를 주고받는다.

  6. TCP에서 복수로 분할된 웹페이지의 파일을 조립해 웹브라우저에 그 내용을 표시하면, 사용자는 웹사이트를 볼 수 있게 된다.

참고