Developer Ahn

Network Layer
: transport segment를 발신 호스트에서 수신 호스트까지 보냄
: sending side는 transport layer에서 segment를 받아 datagrams을 캡슐화
: receiving side는 transport layer로 datagrams에서 segment를 추출하여 전달
: 모든 호스트와 라우터에 network layer protocols 내장 
: 라우터는 입력 링크의 IP datagrams의 헤더 필드를 조사하여 출력 링크로 전달

네트워크 계층의 연결형 및 비연결형 서비스
- 데이터그램 네트워크(datagram network)는 네트워크 계층에서 비연결형 서비스만 제공
- 가상회선 네트워크(virtual circuit network)는 네트워크 계층에서 연결형 서비스만을 제공
- 트랜스포트 계층 서비스와 유사하지만 네트워크 계층 서비스는 다음과 같은 차이
 : 호스트 사이의 서비스
 : 연결형이나 비연결형 서비스 하나만 제공
 : 종단 뿐만 아니라 네트워크 코어의 라우터에서도 구현

Two Key Network-Layer Functions
 
- Forwarding
 : 라우터의 입력 포트에서 출력 포트로 패킷을 이동시키는 것
 : 한 교차로를 지나가는 과정
 : 32비트 IP 주소는 40억개 이상의 주소를 가지므로 라우터 포워딩 테이블이 목적지 주소마다 하나의 엔트리를 갖는다면 아주 큰 테이블이 필요

- Routing
 : 패킷의 출발지에서 목적지까지의 경로를 얻어내는 것
 : 출발지에서 목적지까지 여행을 계획하는 과정
 ■ 라우팅 알고리즘
  : 링크 상태 라우팅 알고리즘

  

 : 거리 벡터 라우팅 알고리즘
  

 : 계층적인 라우팅
    : 모든 라우터가 동일, 하나의 네트워크로 이상적인 환경으로 가정했지만, 실제는 6억개 이상의 호스트로 인해 확장이 어렵고, 여러 조직의 네트워크가 존재하여 관리 자치권부여에 어려움음 겪음
    

Router Architecture Overview

- Two key router functions
 : 라우팅 알고리즘/ 프로토콜 수행(RIP, OSPF, BGP)
 : 입력 링크를 출력 링크로 포워딩
 

- Input Port Functions
   

- Switching Fabric
 
 : memory? 1 세대 라우터, 메모리 대역폭에 따라 속도 제한
 : bus? 버스의 대역폭에 따라 스위칭 속도 제한
 : crossbar? 버스의 대역폭 한계를 극복

- Output Port Functions

IP: Internet Protocol
- 호스트, 라우터의 네트워크 계층 기능
 

- IP datagram format
 

- IP 단편화와 재결합
   

- IPv4 addressing
     

  ■ Subnet
   

  ■ CIDR(Classless Interdomain Routing)
    : /23, 상위 23비트가 서브넷 주소
  

  ■ DHCP(Dynamic Host Configuration Protocol)
    : 호스트가 네트워크에 접속할 때 서버로부터 IP 주소를 동적으로 획득
    : 네트워크에 연결되었을 때만 주소를 가지므로 주소의 재사용 가능
    : 짧은 시간 동안에 네트워크에 연결되는 모바일 사용자 지원
    : 플러그 앤 플레이 (plug-and-play) 프로토콜
    : 할당된 서브넷 IP 주소 외에 첫 번째 홉 라우터의 주소, DNS 서버의 이름과 IP 주소, 네트워크 마스크 (주소에서 네트워크 호스트의 부분을 표시)

     
          

  ■ ICANN(Internet Corporation for Assigned Names and Numbers)
    : ISP가 주소 블록을 획득받는 곳
    : [RFC 2050]을 기반으로 IP주소 할당
    : DNS 관리, 도메인 이름을 할당하고, 도메인 이름 분쟁 해결

  ■ NAT(Network Address Translation)
   : 지역 네트워크는 외부 세계에로는 하나의 IP 주소만을 사용
   : 모든 디바이스에 대해 하나의 IP 주소만을 사용하여, ISP로 부터 여러 개 주소를 할당 받을 필요 없고, 디바이스의 주소를 변경하지 않고 ISP를 바꿀 수 있음
   : 지역 네트워크 내부의 디바이스들은 외부 세계에서 명시적으로 주소지정을 하거나 노출되지 않음 (보안 이점)

   : 16 비트 포트번호 단일 LAN 측 주소로 6만개 동시 연결
   : 포트번호는 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용되어야 함
   : 라우터는 계층 3까지만 처리해야 함
   : 종단 간의 논의에 위반, 호스트가 IP 주소와 포트번호 수정 없이 직접 통신해야 함
   : 주소의 부족은 IPv6로 해결
   : 횡단 문제 해결로 정적 구성, UPnP, 릴레이
   

     

- ICMP(Internet Control Message Protocol) 
 : ICMP는 호스트와 라우터 사이에서 네트워크 계층 정보를 통신하기 위해 사용 (오류 보고, 반향 요청/응답)
 : IP 상위 계층으로 ICMP 메세지는 IP 데이터그램의 페이로드로 전송

- IPv6
 : 32 비트 IP 주소 공간이 빠른 속도로 고갈로 인한 등장
 : 빠른 처리와 포워딩을 지원하는 헤더 포맷, QoS가 용이한 헤더
 ■ IPv6 datagram format
   : 고정된 길이의 40바이트 헤더
   : 단편화(fragmentation)를 허용하지 않음
   : 2¹²⁸ 개로 거의 무한대에 가까운 주소 갯수

    

- IPv4 vs IPv6
  : 체크섬 제거 -> 각 홉에서의 처리 시간 줄임
  : 옵션 제거 -> 더 이상 표준 IP 헤더 필드가 아닌 IPv6 헤더의 '다음 헤더' 중 하나가 될 수는 있음
  : ICMPv6 -> ICMP의 새로운 버전으로 추가적인 메시지 타입, 코드, 멀티 캐스트 그룹 관리 기능 추가
  : IPv4 -> IPv6로의 전환? 모든 라우터들을 동시에 업그레이드 할 수 없음 -> 터널링을 통해 해결
 ■ 터널링
     

브로드캐스트와 멀티캐스트 라우팅
- 브로드 캐스트
   

- 멀티캐스트
 

TCP vs. UDP
: 두 프로토콜 모두 delay, bandwidth guarantees 이용 불가
: 많은 application들은 하나의 transport layer protocol을 사용하므로 Multiplexing and Demultiplexing이 필요함

- TCP(Transmission Control Protocol)
 : 신뢰성, 메세지 순서 보장
 : 연결성(발신자 수신자간 handshaking)
 : point-to-point
 : full duplex (전이중 방식), 하나의 Connection에서 양쪽으로 데이터 흐름
 : 혼잡 제어, pipelined(window size로 혼잡 및 흐름 제어)
 : send & receive buffers
 : HTTP, FTP, SMTP, Telnet 등에 사용


                    TCP segment structure

■ 3-hand-shaking 

■ 4-hand-shaking

- UDP(User Datagram Protocol)
 : 비신뢰성, 메세지 비순서
 : 비연결성(발신자와 수신자간의 handshaking 없이 port만으로 소켓 구별, no-frills extension of “best-effort” IP)
 : 설계방식에 따라 full duplex, half duplex (반이중 방식)
 : reliability를 application layer상에 추가(RUDP)할 수 있지만 app-specific error만 복구 가능
 : RTT가 너무 짧으면 불필요한 재전송 발생, RTT가 너무 길면 느린 reaction과 segment 손실 가능성
 : RIP(Routing Information Protocol), DNS, NFS(Network File System), SNMP(Simple Network Management Protocol)등에 사용

 
                    UDP segment structure

  ■ Checksum
    : segment의 에러 체크
    : header + data + pseudo-header의 sum의 16 bit-one's complement 값
    : 모든 Data값과 checksum값을 더했을 때 모든 bit가 1로 채워져있다면 에러가 없음을 의미, 에러가 검출되면 해당 segment는 버려짐
   

Principles of Reliable data transfer(RDT)
  
   

: FSM(Finite State Machine)? 각각 loop를 돌고 있는 상태
: ACKs(ACKnowledgements)? 수신자가 패킷을 받았다고 발신자에게 보내는 신호
: NAKs(Negative ACKnowledgements)? 수신자가 패킷에 에러가 있다고 발신자에게 보내는 신호(seq# ack로 대체)
: rdt 1.0? 수신, 발신 FSM을 분리 -> rdt 2.0? 에러 복구에 대한 ACK, NAK 도입 -> ACK/NAK 에러 발생시 발신자는 알수없으므로 중복 전송 가능성 -> rdt 2.1? 발신자는 ACK/NAK를 받았을 경우에만 재전송, 각 패킷에 sequence number를 붙임, 수신자는 중복 패킷 버림 (stop and wait) -> ACK/NAK에서 에러가 발생할 경우 전송한 패킷을 재전송 가능성 -> rdt 2.2? NAK 대신 마지막으로 받은 패킷의 seq를 ACK에 붙여 전송 -> 패킷이나 ACK에서 에러나 손실이 발생하면 무한정 기다리게 됨 -> rdt 3.0? time-out 도입

1. Forward Error Correction(FEC)
  : Realtime communication
  : 수신자로 하여금 에러를 수정할 수 있도록 redundant bits를 추가 
2. Retransmission
  : 수신자가 에러를 감지하고 발신자에게 data를 다시 전송해달라고 요청
 : ARQ(Automatic Repeat reQuest)
   : 수신자 피드백 방식, 오류검출만으로도 통신회선의 신뢰성 제고, 실시간 처리에는 부적합한 에러 제어 방법
   : 오류 검출, 수신 여부 피드백, 재전송 기능 등이 필요

   ■ Stop and Wait
     : 한 번에 하나씩 긍정 확인응답(ACK)을 받고, 후속 데이터 전송
     : 가장 단순하나, 다소 비효율적
     : 반이중 방식에서도 가능(Pipelining를 이용하여 효율 증가)

    

   ■ Go back N(GBN or Continuous ARQ)     
     : Pipelining Protocol
     : 반이중 방식
     : Sliding Window 방식
     : 한번에 여러 개를 보낸후 하나의 긍정 확인응답(ACK)을 받고, 후속 데이터 전송.
     : 발신자는 패킷 n에 대해 timeout 발생시 패킷 n과 window 안에 있는 seq #이 n보다 높은 모든 패킷을 재전송
     : 수신자가 예기치 않은 패킷을 받을 경우, 그 패킷을 버리고 가장 최근에 받은 패킷의 ACK를 재전송

    

    

   ■ Selective Repeat
     : Pipelining Protocol
     : 전이중 방식
     : Go back N 과 비슷하지만 오류가 발생된 패킷 이후 또는 오류 발생된 패킷만을 재전송
     : 수신자는 순서가 다르더라도 Receiver Window 안에 포함되는 패킷이라면 받을수 있으며 Buffer 해놓음.

    
    

Web and HTTP
: Web page 는 HTML file, JPEG image, Java applet, audio file 등의 객체들로 구성, HTML-file이 베이스
: 각 객체들은 자체 주소(URL)을 가지고 있음



- HTTP
 : HyperText Transfer Protocol
 : 웹 어플리케이션 레이어 프로토콜
 : client/server model
 : client? 브라우저가 requests, receives 한 웹 객체를 디스플레이 함
 : server? web server가 요청에 대한 응답으로 객체를 전송
 : http는 stateless protocol -> 서버는 클라이언트의 과거 요청을 유지하지 않음
 : RTT? RoundTripTime으로 클라이언트 요청이 서버로 응답이 오는 시간

FTP
: File Transfer Protocol, RFC 959
: 다른 host로부터 혹은 다른 host로 file을 전송할 때 사용하는 프로토콜
: stateful protocol
: client - server model
: transport protocol로 TCP 사용, FTP server는 PORT 21로 control connection(out-of-band), client는 PORT 20로 data connection
: 암호화가 필요하여 최근에는 SFTP나 FTPS로 대체

Electronic Mail
: 주요 3가지 컴포넌트로 user agents, mail servers, SMTP(Simple Mail Transfer Protocol)로 구성
: user agents? mail reader, mail을 읽고, 편집
: mail servers? mailbox + message queue + SMTP

 

: SMTP? mail server 사이에서 메시지 전달을 위해 적용되는 프로토콜
: transport protocol로 TCP 사용, PORT 25
: persistent connection(여러 메시지를 하나의 TCP connection에서 전송 가능)
: handshaking(greeting) -> transfer of message -> closure

- HTTP vs. SMTP
 : HTTP 1.1과 SMTP 둘다 persistent connection
 : 둘다 ASCII 커맨드, status code를 가짐 
 : HTTP는 pull로 client가 요청으로 정보를 끌어옴, SMTP는 push로 요청하지 않아도 server가 mailbox까지 정보를 줌.
 : HTTP는 각 개체가 캡슐화, SMTP는 한 msg안에 여러 객체가 담긴다.

- Mail access protocols
 : POP? Post Office Protocol, TCP 사용, download-and-keep, stateless across sessions
 : IMAP4? Internet Mail Access Protocol, 메세지 ID와 폴더 이름 간 매핑하여 user에게 접근 허가, user stateful across sessions
 : HTTP? gmail, naver 등
 

DNS
: Domain Name System
: IP 주소와 Name의 mapping가 필요함 -> name-address resolution
: hostname을 ip주소로 변환, host aliasing, mail server aliasing, load distribution
: UDP/TCP 둘 다 사용가능하지만 주로 UDP 사용, PORT 53
: 트래픽, single point of failure, 거리, 확장성 등의 문제로 중앙 집권 구조로 구현하지 않고, 분산 데이터베이스로 많은 name server의 계층형태로 구현

: www.amazon.com의 ip 주소를 얻는 과정
1. client가 root server로 com DNS server를 찾기위해 query를 보낸다.
2. client가 com DNS server로 amazon.com DNS server를 찾기위해 query를 보낸다.
3. client가 amazon.com DNS server로 www.amazon.com의 ip 주소를 얻기 위해 query를 보낸다. -> 주소의 역순으로 접근하면서 ip주소를 찾아감
: Root DNS server : 13개 (A~M) 세계적으로 존재
: Top-level domain (TLD) servers? com, org, net, edu, etc, kr, uk, fr, ca, jp 등
: Authoritative DNS servers? 어떤 단체에 대한 DNS 실제적인 IP주소
: Local Name Server? 엄격한 계층구조가 아닌 각 ISP(default name server)를 하나씩 가지고 있음, host가 DNS query를 생성하면 query가 DNS server로 전송, 마치 프록시처럼 계층적으로 query 전달
: caching and updating records

- DNS name resolution

  
:iterated query                                        :recursive query

P2P


- BitTorrent
 : File은 256KB chunks로 쪼개짐
 : peer joining torrent: 시간이 흐름에 따라 chunk가 쌓인다. tracker로 등록하여 주번 peer list를 얻음
 : 다운로드 하는 동안 peer는 chunk를 다른 chunk부터 요청하여 받음, 가장 귀한 chunk부터 요청하여 받음)
 : Free Riding 방지 -> Tit-for-tat -> 많이 주는 쪽을 top-four providers로 선정 


- Centralized index
 : peer들의 정보(ip, content)를 중앙서버에서 찾는 구조
 : single point of failure, 병목현상등의 문제 발생

 
- DHT
 : Distributed Hash Table = Distributed P2P database 
 : DB는 (id, value) pairs 를 가짐, 각 peer 들은 query를 이용하여 (key, value) peers을 얻어낼 수 있음
 : Shortcuts(peer를 찾는 가장 짧은 경로), Peer Churn(Peer가 떠날 경우 successor를 새로 지정)