1. 라우터
인터넷은 어떻게 구성되어 있나?
2. 네트워크 구조
- 네트워크 edge
- 네트워크 웹서버- 어플리케이션
- 네트워크 core
- 라우터- 모양: (x)
- 실제 미디어
2-1. 네트워크 edge
- end systems
- 웹-이메일과 같이 어플리케이션 프로그램 - 클라이언트/ 서버 모델
- 웹프라우저와 서버 모델 - peer - peer 모델
- 할당된 서버들의 최소화된 사용
클라이언트 입장에서의 커넥션-oriented 서비스
TCP
- connection-oriented 서비스를 제공하는 방법
- 1) reliable, in-order byte stream data transfer
데이터를 순차적으로 전송함 - 2) flow control
리시버가 데이터를 전달받는 그 용량에 맞춰서 전달함 - 3) congestion control
네트워킹이 혼잡할때 센더가 데이터 전송 속도를 줄임
클라이언트 입장에서 커넥션-less 서비스
UDP
사용하는 이유?
- 속도가 빠름
센더 입장에서는 마음대로 정보를 계속 보냄 - reliable 하지 않음
UDP와 TCP는 사용자에게 제공하는 기본적인 서비스이다.
- UDP 사용하는 용도 - 신뢰성이 굳이 필요하지 않은 경우
ex) real-time 전화
오디오 패킷 몇개가 유실되도 사용자들이 감지하기 어려움 - TCP : 컴퓨팅 리소스가 필요하기에 그만큼 비용이 듦
프로토콜이란?
TCP (~protocol) UDP (~protocol)
기계 사이에 통하는 '약속'
웹브라우저와 서버 간의 자원을 주고받기 위한 준비동작
ex. 프로토콜이 맞는 사람들끼리 마음이 통함
-> 프로토콜이 맞는 사람들끼리 정보를 주고받을 수가 있음
결국.. TCP와 UDP 모두 얘기하는 방식
네트워크 코어
네트워크의 가운데에는 라우터가 위치한다.
메세지를 전달하는 방식에는 두가지가 존재한다.
- circuit switching
출발지에서 목적지까지 가는길을 예약해놓고 특정 사용자만 사용할 수 있게 해놓은 것
ex) 예전 유선전화 - packet switching
사용자가 보내는 정보를 packet단위로 받아 올바른 방향으로 정보를 내보내는 것
ex) 인터넷
packet switching
패킷 단위로 들어오는대로 내보내는 것
input -> output
자원의 예약같은 게 필요하지 않음
circuit vs packet ?
왜 인터넷 초기 설립자는 packet switching을 선택하였는가?
- 사용자의 제약이 없음
들어오는대로 막 받지만 한꺼번에 여러명이 몰리면 문제가 될 수도 있음.
1) circuit-switching
한꺼번에 많은 사람들이 접속하는 경우
그치만 대부분의 경우 동시에 여러명의 사용자가 접속하는 경우는 자주 있지 않기 때문에 packet switching 을 사용함
따라서 사람들이 몰리지만 않으면 좀더 많은 사람들에게 정보를 전달할 수 있기 때문에 packet switching을 사용함
만약 여러명이 동시 접속이 되면 대기시간이 무한정 길어지게 됨
-> packet switching이기 때문에 어쩔 수 없이 생기게 되는 delay 등의 문제들
패킷전달과정
1) process 검사 과정
-> processing delay
2) outgoing
나가는 v < 들어오는 v 인 경우
들어오는 정보들을 임시로 저장하기 위해 queue/ buffer을 라우터에 둬서 대기시킨다.
이때 앞에 있는 정보들이 모두 나갈때까지 기다리는 시간이 있다.
큐에 집어넣어서 자기 차례가 될때까지 걸리는 시간
-> queuing delay
3) 마지막 비트가 큐의 첫번째로 올라가서 link로 뿌려지는 시간
-> transmission delay
R = 링크의 bandwidth (bps)
L = 패킷의 길이 (bits)
L/R = 링크에서 비트를 내보내는 속도
4) 마지막 비트가 다음 라우터까지 가는데 걸리는 시간
-> propagation delay
delay solution
그러면 delay를 줄이기 위해서 어떤게 있을까?
1) process delay 해결법
좋은 라우터를 구비한다.
2) transmission delay 해결법
케이블 공사를 해서 bandwith를 늘려버린다.
3) queuing delay 해결법
큐의 조절은 클라이언트의 기여도와 연관이 있다.
따라서 조절하기 어렵다.
인터넷 상에서 진행되는 패킷 유실은 queuing delay에서 발생된다.
근데 TCP는 reliable 한 서비스라고 했는데 왜 packet loss가 발생되는 거지?
결국 패킷이 유실되면 재전송을 해야한다. 재전송에는 두가지 방법이 있다.
1) 라우터가 직접 재전송을 한다.
2) 클라이언트가 재전송한다.
인터넷에서는 2) 방식으로 재전송을 진행한다. 중간의 라우터들은 no-brain 으로 패킷의 전달만 진행된다. 모든 network edge들이다. 중간의 라우터는 최대한 단순작업만 하게 내버려뒀다. 만약 중간의 라우터들이 유실작업까지 책임진다면? 인터넷 속도가 느려지게 될 것이다.
라우터에서 생긴 delay ~ 고속도로의 차 상황
1) 차가 라우터~라우터 까지 propagate 하는데 걸리는 속도: 100km/hr
2) toll booth가 차 한대를 서비스하는데 걸리는 시간 12s (= transmission time)
3) 2번째 toll booth 직전까지 카르반이 줄 서기까지 걸릴 시간
12(s) x 10 + 1hr (거의 빛의 속도로 감로) = 62(m)
=> 패킷의 앞부분은 혼자서 앞에 도달했다고 해서 진행되는 것이 아니고 모든 패킷 bit가 toll booth에 도달할때까지 기다린 후 다함께 두번째 toll booth로 감
네트워크 계층
- application
- http - transport
- TCP- UDP
- network
- IP - link
- wifi- LTE
- ethernet
- physical layer
각 계층안에는 다양한 protocol이 존재한다.
client-server 내에만 네트워크 계층이 존재하고
중간의 라우터들은 네트워크까지만 존재한다.
client-server 구조
server
- 고정된 ip 주소를 가짐
서버가 고정되어 있어야 client 가 찾아온다.
client
- 고정되지 않아도 되는 ip 주소
클라이언트와 서버는 프로세스 사이의 통신이다. 각 프로세스의 인터페이스를 socket이 담당한다. 그렇다면 socket1에서 socket2로 통신할때 알아보려면 index가 필요한데 이때 사용될 index 가 ip 주소이다. ip 주소는 컴퓨터를 지칭하는 주소라고 볼 수 있다.
ex) 우리가 naver에 접속할때 'www.naver.com'이라는 socket을 입력한다. 그러나 원래는 naver의 고정 ip 주소를 입력해야 하는데 이 부분이 귀찮기 때문에 도메인으로 입력된다.
DNS에서는 ip주소를 알아보는데 포트번호까지 알아보기엔 일이 복잡해지므로 포트번호는 모두 80으로 통일된다.
transport 계층에서의 역할
보통 클라이언트가 원하는 데이터의 희망사항
1. 내가 보낸 데이터가 목적지까지 정확하게 도착하기 (data integrity)
2. 데이터가 정해진 시간내에 도착하기 (timing)
3. 데이터의 용량이 ~정도까지 보내지기 (throughput)
4. 보안, 데이터 integrity 등등..
transport 계층에서는 데이터의 utility까지만 제공함
(-> TCP만 제공하고 UDP는 제공하지 않음)
유명한 어플리케이션들이 어떤 TCP를 사용할까?
- 가장 유명한 것은 HTTP (웹을 동작시키는 어플리케이션)
HTTP
그렇다면 HTTP에 대해 배워보자
특징)
- HTTP (hyper text transport protocol)
중간중간에 link가 있는 text = hyper text - request(hyper text 파일이름) / response(hyper text에 대한 응답)
- TCP를 사용하기때문에 request-response 이전에 TCP connection 을 사용해야 함
- HTTP는 stateless
HTTP는 단순하기 때문에 request 가 들어오면 그에 대한 response를 보내주고 끝이다.
request에 대한 상태를 기억하지 않는다.
HTTP connection
TCP connection을 사용하는 방식에 따라 2가지로 나뉜다.
1) non-persistent HTTP
TCP connection을 만든후 request-response를 한 후 connection을 끊는다.
2) persistent HTTP
TCP connection을 만든후 request-response를 한 후에도 connection을 지속한다.
non-persistent HTTP
가정) 10개의 ht가 있다.
순서도는 다음과 같다.
1) TCP connection 연결 요구
2) TCP connection을 연결하면서 HTTP request를 받음
3) HTTP response를 보냄
4) response를 받고 TCP connection을 끊음
5) client는 home.index 파일을 parsing함
6) home.index에 있는 10개의 이미지들에 대해 모두 TCP 로 요청함
실제로 TCP connection을 끊을땐 client-server 모두가 TCP connection을 끊어야 한다.
persistent HTTP
..
4) HTTP response를 받은 후에도 TCP connection이 지속되어 연결됨
..
현재 웹브라우저는 persistent HTTP를 사용한다.
가장 좋은 방법은 한꺼번에 요청을 보내는것 -> pipeline
