Application Layer _ Web and HTTP

네트워크 응용 중 가장 많이 사용하는 것은 web이다. web은 HTTP 프로토콜을 사용한다.

 

WEB

web은 hypertext 문서가 연결된 것이다.(인터넷은 네트워크의 연결망임. 웹과 인터넷은 다른의미이다!) 웹을 구성하는 html 코드에 하이퍼링크가 포함되어 있어 하이퍼텍스트라고 한다. 웹페이지는 다양한 요소(object)들을 가지고 있다. 요소들은 html 문서나 이미지, 동영상, 자바코드 등이 해당된다.

 웹페이지는 html 이라는 프로그래밍 언어로 기술된다. html 파일에 다양한 요소들이 포함된다. CSS를 통해 웹페이지의 디자인 요소를 넣기도 하고, 자바스크립트를 통해 동적 요소를 구현하기도 한다. (예전애는 flash 를 깔아야 동영상을 볼 수있었으나, 자바스크립트를 통해 플래시를 설치하지 않아도 되게 됨)

 

※ SGML : 하나의 마크를 넣어 여러세계의 문서를 공유할 수 있는 표기법을 시도했던 방법이다. SGML을 축소시켜 브라우저에 보여주고자 했던 것이 HTML이다.

※ XML : HTML을 확장한 것으로, 태그를통해서 글자의 의미를 부여하고자 하는 것이다. 인터넷의 기본적인 문서가 XML이고, XML을 통해서 DB기능을 활용할 수 있다. 

 

URL

각각의 요소가 존재하는 위치는 URL(Uniform Resource Locator)을 통해서 표시한다. URL의 예시는 내 블로그의 상단에 위치한  https://ins-life.tistory.com/11 이다. 여기서   https://ins-life.tistory.com 는 host name 으로 존재하는 서버의 이름이고, 서버 안에 위치한 오브젝트 파일 중 하나인 11 이 path name 이 된다. 그리고 웹사이트의 오른쪽 마우스 버튼을 클릭하면 이 페이지의 html 문서를 볼 수 있다. 아래는 URL 구성이다

URL 의 구성

 

HTTP

 HTML 문서를 주고받는 통신 프로토콜이 HTTP(HyperText Transfer Protocol)이다. 대표적인 client/server 모델로, client 가 http프로토콜을 이용하여 브라우저를 요청하면 server는 응답을 받아 요청한 데이터를 전달해주고 클라이언트는 받아서 화면에 display한다.

 HTTP 는 비상태 프로토콜이다. 서버는 client의 요청 정보를 기억하지 않는다. server는 나중에 client가 데이터를 또 요청해도 재요청인지 새로운 요청인지 알지 못한다.

 웹 서버는 통신을 위해서 항상 고정적인 ip 주소를 가지고 있어야 한다. 또한 클라이언트에서 요청할 때 어떤 프로세스가 요청했는 지 정확히 알아야 하므로 포트번호도 가지고 있어야 한다. 포터번호는 프로세스 번호이다. 한 호스트 장치에 여러개의 프로세스가 돌아가므로 os 에서는 각 프로세스에 포트번호를 할당해준다. 보통 웹서버는 80번 포트에 연결된다. 보안을 위해 8000,8080 번도 사용한다. 보안이 강화된 https 의 경우 포트번호 443을 이용한다.

 HTTP는 TCP 프로토콜의 도움을 받는다.

 웹프로그램은 문자데이터이기 때문에 신뢰성이 중요하다. 즉, 데이터 손실이 일어나면 안된다. tcp 프로토콜은 연결 전에 3-way handshaking을 통해 데이터 전송의 신뢰성을 확보한다. 서버에 어떤 데이터를 요청하기 전에 tcp connection을 확보하여 http메세지를 교환하게 된다. 데이터 교환이 끝나면 tcp 연결이 끊어지게 된다. 

HTTP 연결에는 지속적 연결과 비지속 연결이 있다. 비지속 연결은 client에서 server에 요청했을 때 여러개의 소켓을 통해 데이터를 받는 것이다. tcp연결에서 한번에 하나의 요소만 전송된다. 다시 말해 동시에 여러 소켓이 열릴 수 있지만, 하나의 소켓에는 하나의 데이터만 전송한다는 것이다. 한 html 문서를 받기 위해서 html 코드를 받기 위한 tcp연결, 이미지를 받기위한 tcp연결, 동영상을 받기 위한 tcp 연결 등등 tcp연결이 별도로 생성되어야 한다. 때문에 오브젝트에 따라 지연시간이 길어진다. HTTP1.0 버전이 비지속적 연결에 해당된다. 

지속적 연결은 하나의 소켓에 연결되면 그 소켓을 확보하여 데이터를 연속적으로 받을 수 있다. 여러개의 요소들이 하나의 tcp 연결을 통해 전송될 수 있다. 지속적 연결이 비지속적 연결에 비해 효율적이기 때문에 지금은 지속적 연결이 더 많이 사용되고 있다. HTTP1.1버전 이후부터 지속적 연결을 사용하고 있다. 

HTTP2.0 버전은 HTTP1.1 버전의 synchronous 문제를 더 최적화 했다. HTTP1.1 버전은 synchronous order을 가진다. 요청한 데이터의 순서와 응답하는 데이터의 순서가 일치해야 한다. 그러면 먼저 요청한 정보가 먼저 오지 않으면 뒤에 응답한 정보들은 대기하므로 그에대한 지연시간이 발생한다. 이런 지연시간을 없애기 위해 HTTP 2.0 버전은 asynchronous order을 허용한다. 어떤 순서로 응답이 와도 그것을 처리할 수 있도록 한다. 뒤의 정보들에 대해 대기시간이 없어지므로 지연 시간을 짧게 만든다. 

tcp 연결에서 client가 server에 패킷을 요청하고 그에 대한 응답이 돌아올 때 까지의 시간을 RTT(round-trip time)이라고 한다. 비지속적 연결은 각 요소들 마다 2RTT + file transmission(object의 크기에 따라 달라지는 시간) 만큼의 시간이 걸린다. tcp 연결은 데이터 전송 전에 연결을 위한 RTT시간이 필요하기 때문이다. 그러나 지속적 연결은 모든 요소들에 대해 RTT만큼의 전송 시간으로 충분하다.

 

HTTP 프로토콜 구조

http 프로토콜의 구조는 위와 같다. http 메세지에는 request 메세지와 response 메세지 두 종류가 있다. 보통 요청하는 쪽의 body 부분에는 내용이 없는 경우가 많다. 자세한 예시는 아래와 같다. 

HTTP request message

요청 메세지의 method 부분에는 GET, POST, HEAD 등의 키워드가 들어간다.

• GET은 서버에게 URL의 웹 문서 전송을 요청한다.
• POST는 클라이언트가 서버에게 정보를 전송할 때에 사용한다.
• PUT 메소드는 블로그 등에 file 단위로 많은 내용의 컨텐츠를 전송할 때 사용한다.
• DELETE는 서버에 파일 삭제를 요청한다. 

이 외에도 PATCH, MOVE, LINK 등의 메소드가 존재한다. 각각의 메소드는 웹서버가 허용할 지 말 지 결정하여 제한한다. 

 

클라이언트가 서버에 정보를 보낼 때에는 POST 메소드나 URL 메소드를 사용한다. POST 메소드를 사용하면 메세지의 body부분에 데이터 형식으로 입력을 넣어서 서버에 업로드하도록 요청한다. URL 메소드는 정보를 요청하면서 정보를 보낸다. 사용하려면 GET 메소드를 사용해야 한다. 업로드 파일을 요청 메세지 헤더 부분의URL 필드에 붙여서 보낸다. URL  메소드는 유튜브 플랫폼에서 사용하는 메소드이다. 

HTTP response message

HTTP 응답 코드는 요청 메세지의 첫번째 줄에 있다. 코드들에는 아래와 같은 것이 있다.

• 200 OK : 요청 성공
• 301 Moved Permanently : 요청한 문서가 이동되었음. 이동된 위치를 알려준다. 
• 400 Bad Request : 서버가 요청 메세지를 이해할 수 없음
• 404 Not Found : 서버에서 요청한 URL을 찾을 수 없음
• 505 HTTP Version Not Supported : http 버전이 달라 통신할 수 없음

Cookie

 HTTP 프로토콜은 기본적으로 stateless 하다. 클라이언트의 상태를 저장하지 않는다는 것이다. 따라서 상태를 저장하려면 cookie를 이용하여 상태를 저장해야 한다. 쿠키는 클라이언트의 state를 저장하기 위한 것이다. 

 위의 그림이 쿠키의 동작 원리이다. 클라이언트가 아마존에 접속하고 싶어 http 요청 메세지를 서버에게 보낸다. 접속하게 되면 아마존 서버는 자동으로 ID하나를 임의로 만들어 유저에게 할당한다. 그리고 고객정보를 저장하는 데이터베이스에 저장하고, http 응답 메세지에도 set-cookie 필드에다가 ID 정보를 담아 전송한다. 그러면 클라이언트는 자신의 쿠키파일에 이러한 id정보를 저장해놓게 된다. 만약 다음번에 아마존에 접속할 때 브라우저는 자신의 쿠키파일을 찾아본다. 그리고 아마존에 대한 기록이 있는지 찾아본다. 있다면, 요청메세지에 쿠키아이디를 같이 보내고, 서버는 쿠키아이디를 기반으로 예전에 클라이언트가 했던 일(ex. 장바구니에 담아놓은 물건, 아이디 저장 등등 )을 전달해준다. 처음 아마존에 접속하기 전에 ebay에 대한 쿠키id 값이 있는데, 이전에 ebay 서버를 방문했던 것을 알 수 있다. 

쿠키는 이렇게 서버가 클라이언트의 state를 유지하기 때문에 프라이버시를 침해하게 될 수도 있다는 문제가 있다. 쿠키는 브라우저의 설정에 들어가서 지울 수 있기에 이런 점이 걱정된다면 삭제하면 된다. 

 

Web Cache(Proxy Server)

 

 어떤 한 기관에 많은 사람들이 접속하는 사이트가 있다. (naver ....) 많은 사람들이 그 사이트에 접속하려면 클라이언트와 서버 사이의 통신이 매우 많아지므로 오버헤드가 커진다. 이러한 문제점을 해결하기 위해 그 기관에서는 proxy server을 둔다. A라는 클라이언트가 서버에 요청한 자료를 origin server에서 제공해주면서 proxy sever에 저장되고, 나중에 B라는 사람이 그 자료를 요청하면 proxy server에서 제공해주게 된다.  B가 데이터를 요청할 때에는 굳이 origin server에서 보내주지 않아도 된다. 프록시서버는 origin server에게는 클라이언트로써 동작하게 되고, 두번째 요청부터 클라이언트에 대해서는 서버로 동작하게 된다. 

 Proxy server를 사용하면 응답시간이 매우 짧아지고, origin server에서 처리해야할 데이터 양이 줄어들어 부담이 적어진다는 장점이 있다. origin server는 같은 용량으로 더 많은 사용자에게 응답해줄 수 있다는 것이다. 

 Proxy server는 클라이언트가 요청한 데이터가 origin server와 같은지 확인한다. 만약 origin server에게 데이터를 받은 날짜와 origin server에 있는 데이터의 작성한 날짜가 같은지 비교하고, 만약 데이터를 받은 이후에 수정된 것이 확인되면 origin server에서 문서를 재전송 해주게 된다.