Vamos ser Programador com Devfon

HTTP 상태 코드

• 상태 코드는 서버로부터 리퀘스트 결과를 전달
• 200 OK와 같이 3자리 숫자와 설명으로 나타남
  • 첫 째 자리는 리스폰스의 클래스를 의미
  • 나머지 2자리는 딱히 분류가 없음
    
    

2xx 성공

2xx 리스폰스는 리퀘스트가 정상으로 처리되었음을 나타냄

• 200 OK: 클라이언트가 보낸 리퀘스트를 서버가 정상적으로 처리하였음
  • 상태 코드와 함께 되돌아 오는 정보는 메소드에 따라 다름
  • GET의 경우, 리퀘스트 리소스에 대응하는 엔티티
  • HEAD의 경우, 리퀘스트 리소스에 대응하는 헤더 필드
• 204 No Content: 리퀘스트는 성공했지만 리소스는 돌려주지 않음
• 206 Partial Content: Range에 의해 범위가 지정된 리퀘스트에 의해 서버가 부분적 GET 리퀘스트를 받음
  
  

3xx 리다이렉트

3xx 리스폰스는 리퀘스트가 정상적으로 처리를 종료하기 위해 브라우저 측에서 특별한 처리를 수행해야 함을 의미

• 301 Moved Permanently: 리퀘스트된 리소스에 새로운 URI 부여되어, 이후로는 바뀐 URI를 사용해야 한다고 알림
  • 따라서 북마크가 설정되어 있는 경우, URI 변경을 할 것을 권함
• 302 Found: 리소스 URI가 일시적으로 다른 곳에 이동되어 있음을 알림
  • 영구적으로 이동한 것은 아니기 때문에 북마크 변경을 권하지 않음
• 303 See Other: 리소스 URI가 다른 곳에 있다는 것을 알림 + GET 메소드의 사용을 권함
  • 302 Found와 같은 기능이지만, GET 메소드의 사용을 권하기 때문에 303을 사용하는 것이 바람직함
  • 301, 302, 303 리스폰스 코드 수신 시 브라우저는 POST를 GET으로 바꾸어 리퀘스트를 자동으로 재송신
    • 301, 302에서는 POST를 GET으로 바꾸는 것을 금지하지만, 실상에서는 변경하는 것이 대부분
• 304 Not Modified: 클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 접근은 허락하지만, 조건이 만족되지 않았음을 알림
• 307 Temporary Redirect: 302 Found와 같은 기능 수행
  
  

4xx 클라이언트 에러

4xx 리스폰스는 클라이언트의 원인으로 에러가 발생했음을 나타냄

• 400 Bad Request: 리퀘스트 구문이 잘못되었음을 나타냄
  • 브라우저는 해당 상태 코드를 200 OK와 같이 취급
• 401 Unauthorized: 리퀘스트에 HTTP 인증 정보가 필요하다는 것을 알림
  • 브라우저에서 처음 401 리스폰스를 받은 경우에는 인증을 위한 다이얼로그가 표시됨
• 403 Forbidden: 리퀘스트된 리소스의 액세스가 거부되었음을 알림
  • 이유를 명확히 하는 경우에는 Entity Body에 기재해서 유저 측에 표시
• 404 Not Found: 리퀘스트한 리소스가 서버 상에 없다는 것을 나타냄
  
  

5xx 서버 에러

5xx 리스폰스는 서버 원인으로 에러가 발생하고 있음을 나타냄

• 500 Internal Server Error: 서버에서 리퀘스트를 처리하는 도중에 에러가 발생했음을 알림
• 503 Service Unavaliable: 일시적으로 서버가 과부하 상태이거나 점검중이기 때문에 리퀘스트 처리가 불가함을 알림
  • 상태가 해소되기까지 걸리는 시간을 Retry-After 헤더 필드에 전달하는 것이 좋음

Network Layer (2)

Routing Algorithm

• Global or decentralized information?
  • global
    • 모든 router는 link cost info를 지녀야 함
    • "link state" algorithms
  • decentralized
    • router는 물리적으로 연결된 이웃과 해당 이웃과의 cost를 알아야 함
    • 연산의 결과에 대해 이웃과 정보 교환을 해야 함
    • "distance vector" algorithms
• Static or Dynamic?
  • static
    • routes가 시간에 따라 느리게 변화
  • dynamic
    • route가 보다 빨리 변경
    • 주기적인 update
    • link cost가 변함에 따라 변경

Link-State: Dijkstra's algorithm

• 모든 node들이 net 상의 link costs를 알고 있음
  • link state broadcast를 통해서!
  • 따라서 모든 node들은 같은 정보를 지니고 있음
• 한 node에서 다른 모든 node로 가는 가장 적은 cost의 path 연산
• 알고리즘 복잡도: n nodes
  • 다른 모든 node들 까지의 거리를 구해야 하므로, O(n^2)
  • 우선순위 큐를 활용하여 O(nlogn) 까지 성능 향상 가능

Distance Vector algorithm

• 각각의 node들은 각각의 이웃과의 cost를 알아야 함
• 시간에 따라 각 node들은 distance vector 추정치를 이웃들에게 전송

• link cost changes:
• node가 local link cost를 감지했을 때
• routing info를 update하고, distance vector 재연산
• DV가 변동되면 이웃에게 알림

Hierarchical routing algorithm

• 여태까지의 routing은 이상적인 case
• 실제로는 그처럼 이상적이지 않음
• 모든 목적지의 정보를 routing table에 저장할 수 없음

• router들을 region에 응집시킴 -> Autonomous Systems
• 같은 AS에 있는 router들은 같은 routing protocol을 따름
  • intra-AS routing protocol
• 다른 AS에 있는 router들은 다른 routing protocol 따름
• Gateway router가 각각의 AS의 입구에 존재
• 해당 AS를 다른 AS와 연결하는 역할

Intra-AS Routing

RIP: Routing Information Protocol

• use distance vector algorithm
• 각각의 link는 1 cost를 의미하며, hops 단위로 계산
• 30초 마다 advertisement를 통해 이웃 간 정보 교환

• 180초 이후에 advertisement 전송 안되면, 해당 이웃/link를 dead 판정
  • 해당 이웃 지나는 route 모두 무효 판정
  • 따라서 새로운 ad를 이웃들에게 보냄

OSPF: Open Shortest Path First

• use link state algorithm(다익스트라 알고리즘)
• 각각의 node에는 모든 cost 비용 존재
• OSPF advertisement는 이웃 당 하나의 entry 나름
  • advertisement는 전제 AS로 퍼짐
• 모든 OSPF 메시지는 악의적 침입을 막기 우해 authenticated
• RIP는 하나의 path만 허용하지만 OSPF에는 같은 cost의 길이 여러 개일 경우, 다수의 paths 허용
• 큰 domain에서는 hierarchical OSPF 사용

Internet inter-AS routing: BGP(Border Gateway Protocol)

• inter-domain routing protocol
• 두 개의 BGP router들이 BGP msg 교환
  • advertising paths to different dest
  • exchanged over semi-permanent TCP connection
• How does entry get in forwarding table?
  • Router가 다른 AS의 prefix임을 인지
    • BGP advertisement를 통해 다른 모든 router들에게 알림
  • 해당 prefix를 위한 router의 output port를 결정
    • BGP route selection을 통해 최적의 inter-AS route 설정
    • OSPF를 사용하여 inter-AS route로 향하는 최적의 intra-AS route를 설정
    • Router가 해당 경로의 prot를 idetify
  • prefix-port entry를 forwarding table에 입력

Why different Intra-, Inter-AS routing ?

• intra-AS: 성능에 초점을 둘 수 있음
• inter-AS: 성능보다 policy에 초점을 맞추어야 함

Broadcast routing

• source로부터 다른 모든 node들에게 패킷 전달
• source packet을 복제하는 것은 비효율적

In-network duplication

• flooding
  • node가 broadcast packet을 받으면 다른 모든 이웃들에게 복사본 전송
  • cycle 생길 위험 있음
• controlled flooding
  • node가 이전에 같은 packet을 broadcast하지 않았다면 해당 packet만 broadcast
  • 이미 broadcast 되었던 packet id를 트랙킹
• spanning tree
  • node들이 여분의 패킷을 전송받을 필요 없음

Spanning Tree

• node들이 spanning tree를 따라 copy를 전송
• 외에도 Shortest path tree, Reverse path forwarding, Steiner tree 등의 구조가 있을 수 있음

Network Layer (1)

Network Layer

• 송신자로부터 수신자로 segment를 전송
• 송신자 측에서는 segment를 datagram으로 캡슐화
• 수신자 측에서는 segment를 transport layer로 전송
• router는 header field의 모든 IP datagram을 검사하여 넘김

Two key network-layer function

• forwarding
  • router의 input에서 적절한 output의 router로 패킷을 전송
• routing
  • 소스로부터 목적지까지 패킷이 전송되어야 할 경로 결정
  • Routing algorithm

Connection setup

• datagrams flow 이전에 두 종단 시스템과 router는 가상의 연결을 맺어야 함
• network: 두 호스트 간의 연결
• transport: 두 프로세스 간의 연결

Connection, connection-less service

• datagram 네트워크는 네트워크 계층의 connection-less service 제공
• virtual-circuit 네트워크는 네트워크 게층의 connection service 제공
• TCP/UDP의 connection-oriented/connectionless와 같음
  • 그러나 host 간 제공되는 서비스이며,
  • 네트워크가 제공하는 circuit 외에는 선택지가 없으며,
  • 네트워크 코어 간 수행된다는 차이 존재

Virtual circuits

• "source-to-dest path behaves much like telephone circuit"
  • performance-wise
  • src-to-dest path와 함께 네트워크적 action이 취해짐
• 각각의 패킷은 Virtual circuit Identifer를 지님(dest host의 주소가 아님)

• VC consists of
  • path from src to dest
  • VC numbers
    • link에 따라 변경될 수 있음
  • entries in forwarding tables
• VC는 현대 인터넷에 사용되지 않음

Datagram networks

• router는 종단 간 연결에 대한 상태를 지니지 않음
• Packet는 단순히 dest host address를 참조해 전송됨

Longest prefix matching

• forwarding table을 참조할 때, 가장 긴 접두부를 공유하는 범위의 Link inferface를 참조하게 되는 것

Router architecture overview

• Input ports
  • datagram의 dest를 보고, forwarding table을 참조하여 output port를 검색
  • forwarding 속도보다 datagram이 빨리 들어올 수 있기 때문에 Queue를 사용하여 Queueing
• Output ports
  • 배출 속도보다 빠른 도착 속도를 고려해 buffer를 두어 buffering
  • datagram Scheduling

Switching fabrics

• 3 types of switching fabrics

Switching via memory

• 1세대 Router
• CPU에 의해 직접적으로 switching
• memory의 bandwidth에 switching 속도 제한됨

Switching via a bus

• 공용 bus를 통해 input port memory에서 output port memory로 datagram switching
• bus의 bandwidth에 의해 switching 속도 제한

Switching via interconnection network

• bus bandwidth의 한계 극복
• 멀티프로세서에 여러 개의 프로세서 연결하기 위해 고안됨
• 이제는 보다 더 발전되어 datagram을 일정 길이로 쪼갠 후, 해당 cell들을 fabric을 통해 switching

The Internet network layer

• IP datagram format

IP fragmentation, reassembly

• network link에는 MTU(max transfer size) 존재
• 때문에 큰 크기의 IP datagram은 분할되어 전송
• 최종 목적지에서 재조립됨

IP addressing

• IP 주소: host와 router interface를 위한 32bit의 식별자
• interface: host/router와 physical link 간 연결 장치
• subnet: router의 간섭 없이 물리적으로 접근 가능한 장치들의 집합(위 그림에는 3개의 subnet 존재)
  • subnetmask가 해당 subnet을 구성할 수 있는 host들의 수 정의

CIDR(Classless Inter-Domain Routing)

• 최신의 IP 주소 할당 방법
• 네트워크 클래스를 대체하고, 기존 방식에 비해 유연성을 더해줌
• 급격히 부족해지는 IPv4 주소를 보다 효율적으로 사용하게 해줌

DHCP(Dynamic Host Configuration Protocol)

• 서버로부터 동적으로 IP 주소를 얻음
• 임대하여 사용 중인 주소 갱신 가능
• 서버와 연결되었을 때만 사용하므로, 해당 주소 재사용 가능

NAT: Network Address Translation

• local network를 하나의 IP로 구성 가능
• local 내의 장치들은 보안성도 얻을 수 있음
  • 외부 세계에 의해 addressable, visible 하지 않기 때문
• NAT router가 알아야 할 것
  • outgoing datagram: 어느 장치에서 출발했는지
  • incoming datagram: 어느 장치로 보내야 할 지
  • NAT translation table
• NAT는 router의 기능을 초과하여 end-to-end system에 간섭하게 되는 단점 존재
  • IPv6를 통해 더 많은 주소 사용 가능해질 것

NAT traversal problem

• client는 10.0.0.1의 특정 server와 연결하고 싶음
• 그러나 공개된 외부 IP 주소는 단 하나이기 때문에 direct 연결이 불가
• solution 1
  • 외부 IP의 특정 port로 접근 요청 시, 바로 10.0.0.1로 forwarding 하게 설정
  • e.g., (123.76.29.7, port 2500) always forwarded to 10.0.0.1 port 25000

• solution 2
  • 10.0.0.1의 host에게 공개 IP 주소를 알림
  • 직접 Port 번호와 Mapping(지정 시간을 두고)

• solution 3
  • relay 서버를 활용
  • relay 서버가 client와 NATed client의 패킷 교환을 중개

ICMP: Internet Control Message Protocol

• host와 router들이 network level의 정보를 교환하기 위해 사용
  • error reporting
  • echo request/reply
• ICMP message는 IP datagram에 들어감

Transition from IPv4 to IPv6

• 모든 router들이 동시에 업그레이드될 수는 없음
• 어떻게 network는 IPv4와 IPv6 router를 혼합해서 사용할 수 있을 것인가?

• Tunneling
  • IPv6 datagram이 IPv4의 payload로 실려다님

Transport Layer

Transport services and protocols

• 다른 호스트에서 동작 중인 어플리케이션 프로세스 간 logical communication을 제공
• Transport protocol은 종단 시스템에서 작동
  • send side: app message를 segment로 쪼개어 network layer로 전달
  • rcv side: segment를 재조립하여 message로 만들어 app layer로 전달
• 1가지 이상의 transport 프로토콜 사용 가능
  • TCP and UDP

Transport vs. network layer

• network layer: logical communication between hosts
• transport layer: logical communication between processes

Internet transport-layer protocols

• 순서가 있는 신뢰성 전달: TCP
  • congestion control
  • flow control
  • connection setup
• 순서가 없는 비신뢰성 전달: UDP

Multiplexing/demultiplexing

• multiplexing at sender:
  • 여러 socket으로 부터 온 data를 transport header에 추가(이후 demultiplexing에 이용됨)
• demultiplexing at receiver:
  • header 정보를 이용하여 요청에 맞는 socket에 전달 받은 segment 전송

How demultiplexing works

• host가 IP datagram을 전송 받음
• 각각의 datagram은 source IP와 destination IP를 지님
• 각각의 transport segment는 source port와 destination port를 지님
• host는 IP 주소와 Port 번호를 이용하여 적합한 socket에 해당 segment 전송!

UDP(User Datagram Protocol)

• 'best effort' service UDP
  • 데이터 유실 있을 수 있음
  • 데이터 순서가 섞일 수 있음
• connectionless: UDP Sender와 Receiver 간 handshaking 하지 않음
• 신뢰성 있는 전송을 위해서는 Application 계층에서 신뢰성을 추가해주어야 함
• 장점
  • connection이 필요 없음(Overhead x)
  • 간단하게 구성 가능
  • header size가 작음

UDP checksum

• Sender
  • 1의 보수로 구성된 checksum을 header의 checksum field에 더함
• Receiver
  • 전송 받은 segment의 checksum을 연산
  • 연산된 checksum이 field 값과 같은지 비교하여 오류 여부 판단

Reliable Data Transfer(RDT)

rdt 1.0: reliable transfer over a reliable channel

• 신뢰성 있는 채널 하에서의 데이터 전송을 가정
  • no bit errors
  • no loss of packets
• 송신자는 채널을 통해 데이터 전송
• 수신자는 채널을 통해 데이터 수신

rdt 2.0: channel with bit errors

• 비트 에러가 존재할 수 있음을 가정
• 에러를 어떻게 복구할 것인가? 'Stop and Wait'
  • ACK: 송신자 -> 수신자. 패킷 잘 받았음!
  • NAK: 송신자 -> 수신자. 패킷 못 받았음!
• 그러나 만약, ACK/NAK에 오류가 생긴다면?
  • 송신자는 수신자의 상황을 알 수가 없음!
  • 중복의 문제로 인해 재전송을 하기도 애매함

rdt 2.1

• 송신자는 ACK/NAK에 오류가 생기면 현재 패킷을 재전송
  • 각각의 패킷에 'Sequence Number 부여'
  • 수신자는 'Sequence number' 확인하여 중복된 데이터 폐기
• 0과 1의 두 가지 sequnce num이면 충분
• 수신자는 기대한 Sequnce number와 전송 받은 번호를 비교하여 중복 데이터 폐기 가능
• 수신자는 자신이 보낸 ACK/NAK가 송신자에게 제대로 전송되었는지 알 수 없음

rdt 2.2 NAK-free protocol

• ACK에 Sequence number를 추가함으로써 잘못된 데이터를 받은 것을 다시 송신할 수 있게 하는 프로토콜

rdt 3.0 channels with errors and loss

• channel에서 패킷도 유실될 수 있음을 가정
• 송신자가 ACK를 기다리는 '적당한' 시간 간격을 둠
  • 이 시간 안에 ACK가 도착하지 않으면 패킷 재전송
  • 만약 패킷이 유실된 것이 아니라 단순 지연으로 인해 늦어진 것이었다면
    • sequnce number가 중복 데이터 처리

Pipelined protocols

Go-Back-N

• 송신자는 N개 만큼의 unacked packet을 파이프라인 통해 전송
• 수신자는 점증적 ACK만을 보냄
• 송신자는 가장 오래된 unacked packet에 timer 부착
  • timer 만료되면, unacked된 모든 패킷을 재전송

Selective Repeat

• 송신자는 N개 만큼의 unacked packet을 파이프라인 통해 전송
• 수신자는 각각의 패킷에 대한 individual ack를 송신자에게 전송
• 송신자는 각각의 unacked packet에 대한 timer 유지
  • timer 만료되면, 해당 unacked packet만 재전송

TCP

• 신뢰성 있는, 순서를 보장하는 전송
• Pipelined
  • congestion, flow control이 window 크기 결정
• connection-oriented by handshaking
• TCP의 Sequence number와 ACK

• TCP의 timeout 설정 기준
  • RTT 보다 길게!
  • 너무 짧으면, 불필요한 재전송하게 됨
  • 너무 길면, segment loss에 느린 대처하게 됨

TCP retransmission scenarios

TCP fast retransmit

• timeout 시간이 상대적으로 긴 경우가 있을 수 있음
  • packet loss 이후에 재전송에 긴 지연이 생김
• 중복된 ACK를 통해 packet loss를 감지 가능
• 만약 송신자가 같은 데이터에 대한 ACK를 3번 받게 되면,
  • 가장 작은 번호의 unacked packet부터 재전송

TCP flow control

• 수신자가 송신자를 제어하여, 수신자의 buffer가 overflow되지 않도록 하는 것
• 수신자는 TCP 헤더의 rwnd라는 값에 여유 버퍼 공간을 알려, 송신자가 너무 많은 데이터를 보내지 못하도록 함

Handshake

• 2-way handshake의 실패 사례

• 3-way handshake

TCP: closing a connection

혼잡 제어의 원리

• "too many sources sending too much data too fast for network to handle"
• lost packets과 long delay를 초래
• 1번 시나리오

• 2번 시나리오

• 2번 시나리오의 이상적 해결안
  • Perfect knowledge: 송신자는 router의 buffer에 공간이 있을 때만 패킷 전송
  • Known loss: packet loss를 인지했을 때만 데이터 재전송
• 현실적 해결안
  • duplicates: 송신자는 패킷의 loss와 drop을 고려하여, 2개의 복사본을 보냄
• 3번 시나리오

혼잡 제어의 2가지 접근법

• 호스트 간의 혼잡 제어
  • 네트워크로부터 피드백 존재하지 않음
  • 종단 시스템에서 loss와 delay의 발생을 보고 혼잡 발생 추론
  • TCP와 같은 접근 취함
• 네트워크 지원 하의 혼잡 제어
  • 라우터가 종단 시스템에게 피드백 제공
  • 송신자의 송신 속도 제어

TCP congestion control

• 송신자는 전송 속도를 서서히 증가시킴
  • loss 발생할 때 까지 증가시키며, 적정 bandwidth를 검증
• additive increase: loss 감지될 때 까지 매 RTT마다 전송 속도 증가
• multiplicative decrease: loss 발생 이후에 전송 속도 반으로 절감
  • TCP Reno: loss 발생 이후, 전송 속도를 반으로 줄임
  • TCP Tahoe: loss 발생 이후, 전송 속도를 1로 줄임

Overview

OSI 7계층 탄생 배경

• 여러 정보 통신 업체 장비들은 타사의 장비와 연결이 되지 않는 등 호환성 문제가 존재
• ISO 단체에서 1984년 OSI 참조모델 발표
• OSI란 네트워크 통신의 개방 시스템 상호 연결 모델(Open Systems Interconnection)
• 모든 시스템들들의 상호 연결을 가능케 하는 표준으로 7개 계층으로 구분

각 계층의 캡슐화와 디캡슐화

• 데이터를 전송할 때 각각의 층마다 인식할 수 있어야 하는 헤더를 붙이게 되는데 이러한 과정이 캡슐화
• 데이터가 전송매체를 통해 전송된 후 1계층 부터 7계층으로 올라가며 헤더가 벗겨지는데 이러한 과정이 디캡슐화

OSI 7계층의 계층별 프로토콜과 기능

• PDU(Process Data Unit)이란 각 계층에서의 전송 단위
• 1계층에서는 PDU이 bit라고 생각하기 쉽지만, 단지 신호의 흐름일 뿐
• 2계층(Frame), 3계층(Packet), 4계층(Segment), 그 이상 계층(Data)

각 계층별 대표적 프로토콜

Application Layer

• 사용자와 가장 밀접한 계층이며, 인터페이스 역할 수행
• 기능: 응용 프로세스 간 정보 교환
• ex) email, internet, media player 등의 application

Presentation Layer

• 기능: 데이터 표현에 차이가 있는 응용처리에서의 제어 구조 제공
  • 데이터 표헌 차이: ASCII, JPEG, MPEG 등의 translation
• 전송하는 데이터의 인코딩, 디코딩, 암호화, 코드 변환 등 수행

Session Layer

• 기능: 통신장치 간 상호작용 및 동기화 제공
• 연결 세션에서 데이터 교환과 에러 발생시 복구 관리
  • 즉, 논리적 연결 담당
• ex) SSH

Transport Layer

• 기능: 종단 간에 신뢰성 있고 정확한 데이터 전송 담당
• 4계층 전송 단위는 Segment이며, 종단 간 에러복구와 흐름 제어 담당
• ex) TCP(Transmission Control Protocol), UDP(User Datagram Protocol)

Network Layer

• 기능: 중계 노드 통하여 전송하는 경우, 어떻게 중계할 것인가를 규정
• 3계층 전송 단위는 Packet이며, Packet을 목적지까지 경로 설정을 함
• 데이터를 목적지까지 가장 안전하고 빠르게 전달하도록 하며, 이를 라우팅이라 함
• ex) IP(Addressing, Fragmentation, Routing)
• 3계층 장비: 라우터, L3 스위치

Data Link Layer

• 기능: 물리적 연결을 통하여 인접한 두 장치 간 신뢰성 있는 정보 전송 담당
• 2계층 전송 단위는 Frame이며, 주소와 제어정보 가짐
• 정보의 오류와 흐름을 관리하여 안정된 정보 전달
• ex) IEEE802.2(LLC), IEEE802.3(CSMA/CD), IEEE802.5(Token Ring)
• 2계층 장비: 브릿지, 스위치

Physical Layer

• 기능: 전기적, 기계적 특성 이용하여 통신 케이블로 전기적 신호 전송
• 인코딩 전압 및 케이블 사양 핀의 수 등을 정의한 계층
• 단지, 데이터 전달의 역할만 수행
• 1계층 장비: 케이블, 리피터, 허브

Application Layer

Application architectures

• Client-Server
• Peer-to-Peer(P2P)

Client-Server architecture

• Server
  • always-on host
  • 영구 IP 주소
  • 규모에 따라 데이터 센터일 수도 있음
• Clients
  • Server와 커뮤니케이션
  • 클라이언트 간 직접 커뮤니케이션 하지 못함
  • 간헐적으로 연결
  • 동적 IP 주소를 가질 수 있음

P2P architecture

• no always-on server
• host들이 자발적으로 직접 커뮤니케이션 -> Self scalability
• peer는 다른 peer에게 서비스를 요청하고, 또 다른 peer에게 서비스를 제공할 수 있음
• peer들은 간헐적으로 연결되며, IP 주소를 바꿈
  • 관리의 어려움

Process communicating

• process: host 내에서 실행 중인 프로그램
• 서로 다른 프로세스가 같은 host에서 실행 중이라면, IPC(Inter Process Communication)을 이용하여 통신
• 서로 다른 프로세스가 다른 host에서 실행 중이라면, Messages를 교환하며 통신
• Client process: 통신을 시작하는 프로세스
• Server process: 다른 프로세스의 연결을 기다리는 프로세스

Sockets

• 프로세스는 메시지를 socket으로부터 받거나, socket으로 전송

Addressing processes

• message를 전달받기 위해서 프로세스는 반드시 identifier를 지녀야 함
• identifer는 IP 주소와 포트 번호를 포함
• ex) HTTP Server은 80번 포트 번호 사용, mail server는 25번 포트 번호 사용

App-layer protocol defines

• message type
  • ex) request, response
• message syntax
  • 어떤 필드값이 있어야 하며, 필드 값들이 어떻게 채워져야 하는지
• message semantics
  • 필드 값들의 의미
• 언제 그리고 어떻게 프로세스들이 메시지를 전송하고, 응답하는지에 대한 rules

Application에 필요한 전송 서비스

• Data integrity
  • 어떤 app들은 100% 신뢰 가능한 데이터 전송을 요구(ex: file transfer)
  • 반면, 어떤 app들은 약간의 손실을 허용(ex: audio)
• timing
  • 어떤 app들은 낮은 지연율을 요함(ex: interactive games)
• throughput
• security
  • 암호화, 데이터 무결성...

Internet transport protocols services

• TCP service
  • 신뢰성 있는 전송
  • flow control
  • congestion control
  • connection-oriented
  • does not provide: timing, minimum throughput guarantee, security
• UDP service
  • 비신뢰성 전송
  • does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, connection set-up

SSL

• 암호화된 TCP 연결을 제공
• data integrity
• end-point authentication
• SSL is at app layer
  • app들은 TCP와 대화하는 SSL 라이브러리를 사용

Web and HTTP

• Web page는 object들로 구성되어 있음
  • object는 HTML file, Image, Audio 등
• Web page는 여러 참조된 object들을 포함하는 HTML file로 구성
• 각각의 object는 URL을 통해 접근 가능
• ex) www.someschool.edu/someDept/pic.gif

HTTP overview

• HTTP: HyperText Transfer Protocol
• Web의 application layer protocol
• Client-Server 모델
  • Client: Web object들을 요청하고, 받고 화면에 보여주는 browser
  • Server: 요청에 대한 응답으로 object를 보내는 Web server
• uses TCP
  • 클라이언트가 80번 포트 번호를 이용하여 서버에 TCP 연결 시작
  • 서버는 클라이언트의 TCP 연결 승인
  • HTTP messages들이 browser와 Web server 간 교환
  • TCP 연결 종료
• HTTP is "stateless(무상태)"
  • 서버는 이전 클라이언트 요청에 대한 어떠한 정보도 저장하지 않음

HTTP connections

• non-persistent HTTP
  • 최대 하나의 object가 TCP 연결 통해 전송 가능
  • 여러 개의 object를 download하기 위해선 여러 번의 연결이 필요
• persistent HTTP
  • 여러 개의 object가 하나의 TCP 연결을 통해 전송 가능

Response Time

• RTT: time for a small packet to travel from client to server and back
• Non-persistent HTTP
  • TCP 연결 시작하기 위한 RTT +
  • HTTP request 위한 RTT +
  • file transmission time =
  • 2 RTT + file transmission time
• Persistent HTTP
  • 서버는 연결을 open 상태로 둠
  • 모든 object를 받기 위해 하나의 RTT만 필요

HTTP request message

• 2개의 HTTP 메시지 타입: request, response

Uploading form input

• POST method
  • Web page는 종종 input form을 포함
  • input이 server에 업로드 됨
• URL method
  • GET method 사용
  • input이 URL의 request line을 통해 업로드
  • ex) www.somesite.com/animalsearch?monkeys&banana

Method types

• HTTP/1.0:
  • GET
  • POST
  • HEAD
• HTTP/1.1:
  • GET, POST, HEAD
  • PUT: URL 필드에 지정된 경로에 파일 업로드
  • DELETE: 특정 URL 필드에 명시된 파일을 삭제

HTTP response message

• status code
  • 200 OK: request 성공, 요청된 object가 이후에 이 msg에 포함될 것
  • 301 Moved Permanently: 요청된 object가 이동함, 이후에 새로운 주소가 이 msg에 명시될 것
  • 400 Bad Request: 서버가 요청 메시지를 처리하지 못함
  • 404 Not Found: 요청된 문서가 이 서버에 존재하지 않음
  • 505 HTTP Version Not Supported

User-Server state: cookies

• 많은 웹 사이트들이 쿠키를 사용
• four components
  • cookie header line of HTTP response msg
  • cookie header line in next HTTP request msg
  • cookie file kept on user's host, managed by user's browser
  • back-end database at Web site

Web caches (proxy server)

• Origin server를 거치지 않고 클라이언트의 요청을 만족하기 위해 사용
• browser가 모든 HTTP request를 cache로 보냄
  • object가 cache에 있다면: cache returns object
  • object가 cache에 없다면: cache가 origin server에 object request 후, client에게 return

Conditional GET

• 목표
  • 만약 cache가 최신의 cached version을 가지고 있으면 object를 전송하지 않음
  • no object transmission delay
  • lower link utilization
• cache: HTTP request에 cached copy의 날짜를 명시
• server: 만약 cached copy가 최신의 것이면 response는 object를 포함시키지 않음

FTP(File Transfer Protocol)

• file을 remote host로/로부터 transfer
• Client-Server model
  • client: side that initiates transfer
  • server: remote host
• 하나의 file 전송 이후에 서버는 data connection 종료
• 서버는 다른 file의 전송을 위해서 다른 TCP data connection을 open
• FTP Server는 'state'를 유지
  • current directory, earlier authentication

E-mail

• Three major components
  • user agents
  • mail servers
  • SMTP(Simple Mail Transfer Protocol)
• User Agent(mail reader)
  • composing, editing, reading mail messages
  • outgoing, incoming messages stored on server
• Mail Servers
  • mailbox는 user에게 온 messages들을 저장
  • message queue는 전송되야 할 mail messages들 담음
  • email messages의 전송을 위한 mail servers들간의 SMTP

SMTP

• reliable transfer를 위해 TCP 사용(25번 포트 번호)
• direct transfer: sending server to receiving server
• Three phases of transfer
  • handshaking
  • transfer of messages
  • closure
• persistent한 연결 사용
• message가 7-bit ASCII로 작성되어야 함

POP3 Protocol

• authorization phase
  • client commands:
    • user: declare username
    • pass: password
  • server responses:
    • +OK
    • -ERR
• transaction phase
  • list: list message numbers
  • retr: retrieve message by number
  • dele: delete
  • quit
• POP3 is stateless across sessions

DNS(Domain Name System)

• IP 주소 대신 'name'을 사용하여 주소에 접근이 가능하게 함
• 분산된 database가 많은 name server들의 계층을 구현
• DNS services
  • hostname to IP addr translation
  • host aliasing
  • mail server aliasing
  • load distribution: 하나의 이름에 많은 IP 주소 설정 가능
• Why not centralize DNS?
  • traffic volume
  • distant centralized database
  • maintenance

DNS: root name servers

• local name server가 name을 처리하지 못할 때 접근하는 서버
• name과 주소의 mapping을 TLD로부터 얻어와 local name server에 return
• 전 세계적으로 13개의 root name server 존재

TLD, authoritative servers

• Top-Level Domain servers:
  • com, org, net, eud, areo, jobs, museums 등과 모든 국가 도메인들을 관리(ex: uk, kr, ca)
• authoritative DNS servers:
  • 기관의 name host들에게 authoritative hostname to IP mapping을 제공하는 기관 소유의 DNS Server
  • 기관 혹은 서비스 제공자에 의해 maintain

Local DNS name server

• 각각의 ISP는 'default name server'라고 불리는 local DNS server 지님
• host가 DNS query를 발생시키면, query는 local DNS server로 전송됨
  • 최근 name-to-address translation 쌍을 local cache에 가지고 있음
  • proxy와 같이 작동하여, query를 계층 구조로 이동시킴
• iterated query

• recursive query

DNS: caching, updating records

• name server가 mapping을 하면, 해당 mapping을 caching
  • cache entry는 TTL 이후에 timeout
  • TLD 서버는 기본적으로 local name server에 cache 되어 있음
    • 그러므로 root name server는 많이 방문되지 않음
• cached entry들은 out-of-date인 것일 수 있음 만약 name host가 IP 주소를 바꿔도, 모든 TTL이 만료될 때 까지 다른 Server들은 해당 변경을 알 수 없음

Attacking DNS

• DDos attacks
  • root server의 traffic을 폭주 시킴
    • traffic filtering을 통해 예방 가능
  • TLD server의 traffic 폭주시키는 것이 더 위험
• Redirect attcks
  • Man-in-middle: query 가로채기
  • DNS poisoning: DNS 서버에 위조 정보 전송