http://www.kocw.net/home/cview.do?cid=6166c077e545b736
컴퓨터네트워크
인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.
www.kocw.net
인터넷은 매우 크다. 우리는 그 가장자리 network edge에 있다. 웹 서버 또한 가장자리에 위치한다.
인터넷의 가운데 부분 network core에 위치하는 건 라우터다. 라우터는 메세지를 전달받아서 목적지로 전송하는 일을 한다. 인터넷은 어떤 요소들로 구성되어 있을까?
Network Structure
- network edge
- 애플리케이션, host
- network core
- routers
- network of networks
- access networks, physical media
- communication links
- 라우터 사이의 링크, 모뎀 선, 이더넷 케이블, 무선 링크 등 ..
- communication links
Network Edge
- client
- 원할 때 네트워크에 접속해서 서버로부터 정보를 가져옴
- server
- 항시 네트워크에 연결되어 클라이언트로부터 요청을 기다림
network edge에 있는 클라이언트와 서버가 통신한다. 인터넷을 통해 소통하고 2가지 방식이 있다.
connection-oriented service
TCP
TCP가 connection oriented service를 제공하는 통신 방법이다. TCP는 사용자에게 3가지를 제공한다
- reliable, in-order byte-stream data transfer
- reliable : 메세지가 유실되지 않고 그대로 감
- in-order byte-stream data transfer : 내가 보낸 메세지 순서를 지킴
- flow control
- sender가 receiver의 속도에 맞춰 데이터를 전송함
- congestion control
- 둘 사이의 네트워크 상태에 맞춰서 네트워크가 감당할 수 있는 만큼 맞춰서 보내줘야 함
- sender는 network가 congested되면 sending rate를 slow down 함
웹 브라우저가 TCP를 사용한다.
UDP
UPD는 connectionless servie를 제공한다.
- connectionless
- unreliable data transfer
- no flow control
- no congestion control
아무것도 안해준다. 왜 쓰일까? 굳이 reliable 하지 않은 context인 경우에 사용한다. 전화같은 real time voice는 audio packet이 몇개 유실되어도 사람들이 체감하지 못한다.
패킷
패킷은 편지봉투다. 패킷 안에 실제 보내고자 하는 메세지가 들어있다.
UDP는 그냥 편지봉투에 편지 넣어서 보내는것, TCP는 등기에 비유할 수 있다. 등기의 단점은 더 비싸다는 것이다. TCP도 제공해주는 기능이 더 많지만 컴퓨팅 리소스, 네트워크 리소스라는 비용이 더 든다.
프로토콜
프로토콜은 대화를 하기 위한 약속이다. 중요한 메세지를 주고받기 위한 준비동작이다. TCP의 UDP의 P가 Protocol이다.
network core
mesh of interconnected routers, 연결된 라우터들의 집합이다.
net을 통해 데이터를 송신하는 방법은 2가지가 있다.
circuit switching
출발지 -> 목적지의 길을 미리 예약해놓고 특정 사용자만을 위해 사용하게 한다. 과거 유선 전화망의 방식이다.
packet switching
메세지를 packet 단위로 받아서 그때그때 올바른 방향으로 forwarding 해준다.
패킷스위칭 vs 써킷스위칭
1Mbps = 1MegaBit/second이다. 아무튼 위와 같은 라우터가 있다고 치자.
써킷스위칭
각 유저당 100kbps로 데이터를 보낸다고 가정하자. 써킷스위칭 방식에서는 1M/100K = 10명의 유저가 사용할 수 있다.
패킷스위칭
정해진 제한은 없다.
사람들이 인터넷을 사용하는 패턴이 있다. 쉴새없이 데이터를 요청하는 것이 아닌 요청 - 쉼 - 요청 -쉼.. 의 패턴이다.
따라서 모든 유저가 동시에 요청을 보내는 것만 아니면 다른 유저가 쉬는 시간에 다른 유저의 요청을 처리할 수 있다.
반면 써킷스위칭 방식을 쓰면 10명만 사용할 수 있고 그 10명이 요청을 하지 않는 순간에는 낭비가 발생한다.
패킷스위칭에서는 사용자들이 총 시간의 10% 정도만 랜덤한 시간에 인터넷을 사용한다고 하면 35명이 동시에 사용해도 10명 이상이 동시에 데이터를 요청할 확률은 0.0004 미만이다.
패킷스위칭 방식이 보다 많은 사람에게 인터넷을 제공할 수 있어서 효율적이기 때문에 인터넷은 패킷스위칭을 채택했다.
패킷스위칭에서 발생하는 delay들
- processing delay
- 패킷을 받으면 에러 확인, output link 정함
- 라우터 성능이 좋아지면 감소한
- queueing delay
- 내가 패킷을 보내는 속도보다 받는 속도가 더 빠르면 패킷을 줄세워서 보내야 함
- 이를 위해 queue(혹은 버퍼)가 있음
- 패킷의 순서가 될 때까지 큐에서 기다리는 시간
- 사용자들이 데이터를 동시에 많이 보내서 큐가 길어져서 발생하는 딜레이이므로 어떻게 조절할 수 가없음
- 큐의 크기는 한정되어 있는데, 패킷이 계속 들어오면 버림 -> packet loss 발생. 대부분의 loss는 이렇게 발생함
- transmission delay
- 패킷은 데이터이므로 bit로 구성됨
- 패킷의 첫번째 bit가 링크로 나가기 시작해서 마지막 bit가 나갈 때까지의 시간
- L/R , L = 패킷 크기, R = 링크 대역폭
- 즉 대역폭 R이 커질수록 작아짐
- propagation delay
- 마지막 비트가 링크에 올라와서 목적지에 도착할 떄 까지의 시간
- d/s, d=링크의 길이, s=전송 속도(빛의속도)
TCP는 reliable하다. 즉 packet loss 없이 목적지에 도달해야 한다. 따라서 loss 된 packet에 대해 재전송한다.
재전송에도 신경써야 할 것들이 있다. 최초 전송한 곳에서 재전송할지, 라우터에서 재전송할지 정해야 한다.
TCP에서는 최초 전송한 곳(network edge)에서 재전송한다. edge(client, server)에 모든 intelligence가 집약되어 있고 core에 해당하는 router는 전달만 한다. 라우터는 전달한다는 단순작업만 빨리 하는게 목적이다.
패킷의 실제 전송속도는 광속이므로 매우 빠르다. 따라서 패킷의 앞부분은 거의 링크에 진입하자 마자 다음 라우터에 도달하고 나머지 패킷들은 이전 라우터에서 transmisson 과정에 의해 링크에 한 비트씩 올라가는 상황이다. 패킷의 앞부분은 먼저 다음 라우터에 도달했다고 해서 그 다음 라우터로 이동하는 것이 아니라, 패킷의 뒷부분이 모두 도달해 하나의 패킷이 될 때까지 기다린다.
네트워크 계층구조
네트워크는 (상단 app, transport, network, link, physical 하단)의 계층구조로 이루어진다.
각 계층에는 다양한 프로토콜이 존재한다.
app - HTTP, transport - TCP/UDP, network - IP, link - wifi/lte/3g/ethernet 등 ...
애플리케이션 계층에 있는 건 네트워크 기능이 있는 프로세스다.(운영체제에서 배운 프로세스) ex) 웹브라우저
우리가 애플리케이션을 개발할 때 physical layer에 중간에 라우터가 있다는 사실은 알지만, 신경쓸 필요 없다. 반대편에 있는 프로세스와 프로세스간의 통신이라고 생각하면 된다.
참고로 라우터에는 physical, link, network 계층까지만 존재한다. 얘내들은 바보임.
IPC(interprocess communication)을 위한 인터페이스를 os에서 만들어놓음. 다른 pc 간 프로세스 통신도 마찬가지임. os가 인터페이스를 만들어 놓음. 그게 바로 socket이다.
socket의 주소를 알아야 접근할 수 있고 그 역할을 하는 것이 IP 주소 + port이다.
IP 주소는 PC마다 갖는 주소다. 하지만 PC에 여러개의 프로세스가 있다. 그래서 컴퓨터 안에서 특정 프로세스를 지칭하기 위해 포트를 사용한다.
원래는 IP주소+포트번호를 입력해야 하지만 우리는 www.naver.com과 같은 url을 입력한다. 사람들의 편의를 위한 것이고 DNS에 의해 IP주소로 해석한다. (포트번호는 생략하면 알아서 넣어줌)
웹 서버는 다 80포트를 사용한다(아마존, 네이버, 구글...) 왜일까? 왜 80인가가 아니라 왜 공통된 포트를 사용할까?
DNS가 IP 변환까지는 해주지만 포트번호는 모른다. 포트번호가 웹 서버마다 다르면 불편하기 때문에 공통되게 80으로 하도록 하고 생략하면 80을 넣어주는 것이다. 즉 편의성을 위함이다.
클라이언트-서버 구조
- 클라이언트
- 웹브라우저
- 동적 IP를 가짐
- 서버
- 웹 서버 - 24시간 동작
- 영구적인(바뀌지 않고 고정된) IP 주소 가짐
- 인터넷상에 존재하는 모든 컴퓨터는 각자의 주소인 IP 주소를 가짐
- 고정되어 있어야 찾아갈 수 있기 때문
- 웹 서버는 80 포트 사용
transport 계층 기능
하위 계층이 상위 계층에게 기능을 제공한다. 즉 application 레이어는 transport 레이어에서 제공하는 기능을 사용한다.
애플리케이션 입장에서 트랜스포트 계층에게 어떤 기능을 제공받고 싶을까? (희망사항)
- data integrity
- 데이터가 온전하게 목적지까지 도달
- timing
- 데이터가 ~안에 목적지에 도달(시간)
- throughput
- 최소 1gbps의 throughput(처리량=단위시간당 데이터전송량)을 가짐
- security
- 보안
하지만 위 희망사항들 중 실제로 transport layer가 제공하는 것은 integrity밖에 없다. (TCP가 제공, UDP는 제공 X)
따라서 제공 안되는 기능들은 애플리케이션 레이어에서 구현함
웹과 http
HTTP = Hypertext transfer protocol = hypertext를 전송하는 프로토콜이다.
hypertext = 중간중간에 다른 text로 넘어갈 수 있는 링크가 있는 text
request와 response 두가지 종류가 있다. 클라이언트가 HTTP 요청을 하면 서버가 HTTP 응답을 해준다.
- HTTP는 TCP를 사용함
- HTTP는 애플리케이션 레이어 프로토콜이므로 트랜스포트 레이어의 기능을 사용함(TCP)
- 따라서 HTTP 요청, 응답을 하기 위해서 TCP connection을 해야함
- HTTP는 stateless
- 상태가 없다
- 요청이 들어오면 데이터 읽어서 보내주고 끝. 상대방에 대한 상태를 기억하지 않음
HTTP는 그리고 TCP를 사용하는 방식에 따라 2가지로 나눠짐. TCP 연결을 persistent하게 사용하는지 아닌지의 차이다.
클라이언트가 서버에게 index.html 파일을 요청하는 상황을 가정하자. index.html은 text랑 image여러개의 참조로 구성됨
- persistent HTTP
- TCP 연결을 HTTP 요청-응답 이후에 유지함
- TCP 연결을 끊지 않고 index.html과 참조하는 그림파일을 모두 요청,응답
- non-persistent HTTP
- HTTP 요청-응답 이후에 TCP 연결 해제
- TCP 연결 -> home.html 요청,응답 -> TCP 연결 끊음
- TCP 연결 -> 그림파일1 요청,응답 -> TCP 끊음 , ... 모든 그림파일에 대해 반복
실제 웹브라우저에서는 persistence HTTP를 사용함
그리고 실제로는 persistent HTTP에서도 각 이미지 별로 HTTP 요청,응답 m HTTP 요청,응답, HTTP 요청,응답.. 하지 않고
한번에 모든 이미지에 대해 HTTP요청,요청,요청,요청 --> HTTP응답,응답,응답,응답.. 의 방식을 사용한다
