티스토리 뷰

반응형

브라우저에 maps.google.com을 입력했을 때 일어나는 일들을 여덟 단계로 정리할 수 있다.

1. 브라우저 주소창에 maps.google.com을 입력한다.
2.HTTP를 사용해서 웹서버에 요청을 보낸다.
3.브라우저가 해당 서버와 TCP 연결한다.
4.TCP가 데이터를 IP에 전달한다.
5. 브라우저가 maps.google.com의 IP 주소를 찾기 위해 캐시에서 DNS 기록을 확인한다.
6.만약 요청한 URL(maps.google.com)이 캐시에 없다면, ISP의 DNS 서버가 DNS 쿼리로 maps.google.com을 호스팅하는 서버의 IP 주소를 찾는다.
7.브라우저가 웹서버에 HTTP 요청을 보낸다.
8.서버가 요청을 처리하고 응답을 보낸다.
9.서버가 HTTP 응답을 보낸다.
10.브라우저가 HTML 컨텐츠를 보여준다.

 

1. 브라우저 주소창에 maps.google.com을 입력한다.

통신과정에서 각 계층을 지나는 데이터는 패킷 단위로 작게 쪼개져 부가 정보(ex. 목적지 정보)가 헤더의 형태로 덧붙여짐

 

애플리케이션 계층 (HTTP,서버,클라이언트..)
 :메세지 단위로 송신됨
 + 상대방에게 보낼 데이터
           - > 애플리케이션 계층
: 수신된 데이터
트랜스포트 계층 ( TCP, UDP)
 : 전송하기 적합한 크기로 작게 쪼갬(세그먼트.데이터그)

 +헤더 붙임
   : 데이터의 결합 순서와 이 데이터를 받은 
     프로그램을 식별할 수 있는 번호
트랜스포트 계층
인터넷 계층 (IP 어드레스, 라우팅...)
 : 수신측의 컴퓨터를 식별할 수 있는 정보를 덧붙임

+헤더 붙임
  : 목적지의 컴퓨터를 식별할 수 있는 번호
인터넷 계층
네트워크 인터페이스 계층 (이더넷, LAN, MAC 주소.)
 : 하드웨어에 신호를 전달하는데 필요한 정보

+헤더붙임
  : 유선 LAN에서 데이터를 보내는데 필요한 정보
네트워크 인터페이스 계층

수신지에서는 송신지의 같은 게층에서 덧붙인 정보를 확인후에 해당 계층이 해야할 일을 처리

* header : 데이터 앞에 붙이는 정보

* trailer : 뒤에 덧붙이는 정보

2. HTTP를 사용해서 웹서버에 요청을 보낸다.

*HTTP : 클라이언트 PC의 웹 브라우저와 웹서버는 HTTP라는 애플리케이션 계층의 프로토콜을 사용한다.

HTTP는 무상태 프로토콜이여서 요청-응답을 한번씩 주고 받은 후에 통신이 끊어진다.

-> 이전의 보낸/받은 정보를 기억못하고 새로운 request가 보내질때마다 새로은 rseponse가 생성됨

 

* 그럼에도 stateless 상태 프로토콜을 쓰는 이유?

 

 

 

*쿠키로 세션을 유지한다. (로그인을 하고 다른 페이지 이동시 로그인 상태를 유지하고 싶을때)

  1. 처음 접속을 하는 경우 요청에 대한 응답에 쿠키를 함께 보낸다. (Set-Cookie 라는 문자열을 넣음)
  2. 쿠키가 클라이언트 PC에 저장된다.
  3. 다음 요청부터 메시지를 보낼때 쿠키를 함께 보낸다.
  4. 쿠키를 보고 같은 사용자의 요청인지 판단한다.

*HTTP 메소드

GET 리소스 획득 request URI로 식별된 리소스를 가져올 수 있도록 요구함.
ex. 리소스가 텍스트면 그대로 반환, CGI와 같은 프로그램이면 실행해서 출력된 내용을 돌려줌
POST 엔티티 전송  
PUT 파일 전송 request중 포함된 엔티티를 request URI로 지정한곳에 보존하도록 요구
단지, HTTP/1.1 PUT자체에는 인증 기능이 없어 누구든지 파일을 업로드 가능하다는 보안상의 문제때문에 웹사이트에서는 사용하지 않는다.
DELETE 파일 삭제 request URI로 지정된 리소스의 삭제를 요구
단, HTTP/1.1는 인증기능이 없기 때문에 일반적인 웹사이트에는 사용하지 않는다.

 

 

3.브라우저가 해당 서버와 TCP 연결한다.

서버측의 포트번호는 고정되어있기 때문에 (80) 여러 클라이언트가 서버와 통신하는 과정에서 같은 포트로 요청이 몰리게된다.

서버는 클라이언트(웹브라우저의 경우 포트번호가 애당초 정해져있지않고 다이나믹 포트를 사용함)의 IP Address와 포트번호를 조합하여 클라이언트를 식별한다.

 

트랜스포트 계층의 역할은 애플리케이션계층의 프로그램에서 전달받은 데이터를 목적지 애플리케이션 계층의 프로그램까지 전달하는 것이다. 데이터가 제대로 전달되지 않았을때 재 전송을 한다.

  1. 어떤 프로그램들이 서로 통신을 해야하는지에 대한 정보를 헤더에 기록한다.
  2.  포트번호를 확인하고 웹서버에 데이터를 전달한다. (어느 어플리케이션으로 보내져야할지 포트번호를 보고 그 패킷을 전달한다.)
  3.  요청을 보낸 프로그램을 목적지로 설정하여 응답 데이터를 전달한다.

 

*데이터의 정확한 전달을 중요시하는 TCP

수신지의 통신환경에 맞춰 데이터 크기를 정하거나 연속된 데이터를 몰아서 보낼 갯수를 정한다.

도달하지 않은 패킷이 있다면 재전송을 요청한다.

이때 어플리케이션계층에서 송신된 메세지단위를 세그먼트라는 단위로 나눈다.

 TCP의 통신방법 3 Way handshake

   * 통신 시작

   

     

 

 1. TCP 헤더중 컨트롤 비트에 SYN을 On으로 설정하고 서버에게 보냄

 2. 서버에게서 ACK 답변받음

 3.   TCP 헤더중 컨트롤 비트에 ACK을 On으로 설정하고 서버에게 보냄
(만약 ACK가 On으로 설정된 패킷이 응답으로 돌아오지 않으면 제대로 전달되지 않은것이라고 판단하고 다시 패킷을 요청한다.)

 

 

 

 

 

*데이터의 전송속도를 중요시 하는 UDP

동영상 스트리밍 서비스와 같이 실시간 통신이 필요하다면 전송속도를 중시하는 UDP를 사용한다.

도달하지 않은 패킷이 있다면 별다른 처리를 하지않아 속도가 빠르다.

 

 UDP의 통신방법 Broadcast & Multicast

하나의 패킷을 여러 수신지에 전달하는 기능으로 네트워크 내의 여러 컴퓨터나 통신 장비와 정보를 교환할때 사용된다.

 

4.TCP가 데이터를 IP에 전달한다.

5. 브라우저가 maps.google.com의 IP 주소를 찾기 위해 캐시에서 DNS 기록을 확인한다.

캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스 복사본을 가르킨다.

(프록시란 서버와 클라이언트 양쪽 역할을 하는 중계프로그램으로 client- request -> server,  client <-response -server 전송 한다.) 

캐시를 사용하면 리소스를 가진 서버 access를 줄이는 것이 가능하기 때문에 통신량과 통신시간을 절약할 수 있다.

 

장점 : 캐시를 이용함으로써 같은 데이터를 몇번이고 서버에 전송할 피요가 없고 클라이언트는 네트워크에서 가까운 서버로 부터 리소스를 얻을 수 있게 되어 서버는 같은 request를 매번 처리하지 않아도 된다.

 

*캐시에도 유효기간이 있다

원래 리소스가 갱신되는 경우 캐시서버는 갱신되기 전의 낡은 resource를 계속 가기고 있게 되므로 캐시를 가지고 있어도 클라이언트의 요구나 캐시의 유효기간등에 의해서 서버의 resource의 유효성을 확인하거나 새로운 리소스를 획득하러 가는 경우도 있다.

 

6.만약 요청한 URL(maps.google.com)이 캐시에 없다면, ISP의 DNS 서버 DNS 쿼리로 maps.google.com을 호스팅하는 서버의 IP 주소를 찾는다.

하나의 HTTP서버에 여러개의 웹사이트를 실행할 수 있는 가상 호스트를 가지고 있어서 고객마다 다른 도메인을 가지고 다른 사이트를 실행 할 수 있다. (물리적으로 서버가 1대지만 가상으로 여러대가 있는것처럼 설정하는것이 가능)

7.브라우저가 웹서버에 HTTP 요청을 보낸다.

*패킷을 쓰는 이유

파이프를 직접 연결하는 회선교환의 경우 회선이 통신으로 인해 점유되면 더이상 추가적으로 접속할 수 없어서 동시에 다수의 컴퓨터가 송수신 할 수 없다. (회선수가 많아야만 가능) ex. 회선3개면 3쌍의 전화기만 통화 가능

패킷교환의 경우 여럿으로 분할해서 송신하는 방식으로 큰 데이터를 작게 나누어 송신한다.

장점 : 패킷 1개를 보내는 시간이 짧아지고, 회선을 점유하는 시간이 짧아져 복수의컴퓨터가 회선을 공유할 수 있게 된다.

          수신처가 연결되어 있는 회선을 골라서 거기로 패킷을 보낸다.

          만약 사용중이라면, 일시적으로 저장했다가  전송해서 복수의 컴퓨터가 동시에 사용할 수 있다.

단점 : 패킷마다 따로 송신하기 때문에 반드시 송신한 순서대로 수신처에 도착하지 않고 도착 시간도 불규칙해서 정확도가 떨어진다.

8.서버가 요청을 처리하고 응답을 보낸다.

9.서버가 HTTP 응답을 보낸다.

1xx Informational 리퀘스트를 받아들여 처리중
2xx Success 리퀘스트를 정상적으로 처리했음
3xx Redirection 리퀘스트를 완료하기 위해서 추가 동작이 필요
4xx Client Error 서버는 리퀘스트 이해 불가능
ex.404 request resource가 서버상에 없
5xx Server Error 서버는 리퀘스트 처리 실패

10.브라우저가 HTML 컨텐츠를 보여준다.

https://www.slashroot.in/difference-between-segments-packets-and-frames

https://www.rfwireless-world.com/Terminology/Segment-vs-Packet-vs-Frame.html

반응형

'Network' 카테고리의 다른 글

[Network] RESTful API  (0) 2023.03.09
[Network] URL vs UR vs URN  (0) 2023.03.02
[Network] HTTP 개념  (0) 2020.04.16
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함