1. 6. TCP/IP
주요 내용
OSI Transport Layer
TCP/UDP

2. OSI 트랜스포트 계층(Transport Layer) 컴퓨터 네트워크(안순신,김은기 저) 참조
주 기능
종단간 데이타 전송
링크 계층과 유사한 기능
인터페이스

3. 서비스의 질(Quality Of Services, QOS)
영향을 미치는 요소
연결 설정시의 지연 시간
전송 속도
전송 지연
에러율 보호
우선 순위

4. TCP/IP 응용 계층 구조

5. TCP(Transmission Control Protocol)
Features of TCP
Connection oriented
Point-to-point: A TCP connection has two endpoints
Reliability: TCP guarantees data will be delivered without loss, duplication or transmission errors
Full duplex
Stream interface: Application delivers data to TCP as a continuous stream
Reliable connection startup: Three-way handshake guarantees reliable, synchronized startup between endpoints
Graceful connection shutdown: TCP guarantees delivery of all data after endpoint shutdown by application

6. TCP 프로토콜 상위 계층의 구조

7. TCP 계층 서비스 수행 과정의 예

8. TCP 계층 PDU 구조

9. TCP/IP 계층의 주소 구조

10. TCP 프로토콜 메카니즘 Connection establishment: Three-way handshake
Data transfer
Error detection and retransmission
Sequence Number, Ack. Number, Checksum field
재전송 timer
Flow control
Window size
Congestion control
Connection release: Three-way handshake

11. UDP(User Datagram Protocol)
UDP 프로토콜 PDU 구조

12. TCP와 UDP의 비교

13. Transport services and protocols
provide logical communication between app’ processes running on different hosts
transport protocols run in end systems
transport vs network layer services:
network layer: data transfer between end systems
transport layer: data transfer between processes
relies on, enhances, network layer services
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical

14. Transport-layer protocols
Internet transport services:
reliable, in-order unicast delivery (TCP)
congestion
flow control
connection setup
unreliable (“best-effort”), unordered unicast or multicast delivery: UDP
services not available:
real-time
bandwidth guarantees
reliable multicast
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical

15. Multiplexing/demultiplexing
Recall: segment - unit of data exchanged between transport layer entities
aka TPDU: transport protocol data unit
Demultiplexing: delivering
received segments to
correct app layer processes
receiver P3 P4
application-layer
data M M
application
transport
network
segment
header P1 P2 M M
application
transport
network
application
transport
network
segment H t M H n
segment

16. Multiplexing/demultiplexing
gathering data from multiple
app processes, enveloping
data with header (later used
for demultiplexing)
32 bits
source port #
dest port #
other header fields
multiplexing/demultiplexing:
based on sender, receiver port numbers, IP addresses
source, dest port #s in each segment
recall: well-known port numbers for specific applications
application
data
(message)
TCP/UDP segment format

17. Multiplexing/demultiplexing: examples
source port: x
dest. port: 23
Web client
host C
host A
server B
source port:23
dest. port: x
Source IP: C
Dest IP: B
source port: y
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
port use: simple telnet app
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Web
server B
Web client
host A
port use: Web server

18. UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be:
lost
delivered out of order to app
connectionless:
no handshaking between UDP sender, receiver
each UDP segment handled independently of others
Why is there a UDP?
no connection establishment (which can add delay)
simple: no connection state at sender, receiver
small segment header
no congestion control: UDP can blast away as fast as desired

19. UDP: more often used for streaming multimedia apps loss tolerant
rate sensitive
other UDP uses (why?):
DNS
SNMP
reliable transfer over UDP: add reliability at application layer
application-specific error recover!
32 bits
source port #
dest port #
Length, in
bytes of UDP
segment,
including
header
length
checksum
Application
data
(message)
UDP segment format

20. UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
Receiver:
compute checksum of received segment
check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected. But maybe errors nonethless? More later ….
Sender:
treat segment contents as sequence of 16-bit integers
checksum: addition (1’s complement sum) of segment contents
sender puts checksum value into UDP checksum field

21. TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 full duplex data:
bi-directional data flow in same connection
MSS: maximum segment size
connection-oriented:
handshaking (exchange of control msgs) init’s sender, receiver state before data exchange
flow controlled:
sender will not overwhelm receiver
point-to-point:
one sender, one receiver
reliable, in-order byte steam:
no “message boundaries”
pipelined:
TCP congestion and flow control set window size
send & receive buffers

22. TCP segment structure source port # dest port # application data
32 bits
application
data
(variable length)
sequence number
acknowledgement number
rcvr window size
ptr urgent data
checksum F S R P A U
head
len
not
used
Options (variable length)
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
ACK: ACK #
valid
PSH: push data now
(generally not used)
# bytes
rcvr willing
to accept
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)

23. simple telnet scenario
TCP seq. #’s and ACKs
Seq. #’s:
byte stream “number” of first byte in segment’s data
ACKs:
seq # of next byte expected from other side
cumulative ACK
Q: how receiver handles out-of-order segments
A: TCP spec doesn’t say, - up to implementor
Host A
Host B
User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs
receipt
of echoed
‘C’
Seq=43, ACK=80
time
simple telnet scenario

24. TCP: retransmission scenarios
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
time
lost ACK scenario
Host B X
Host A
Host B
Seq=92, 8 bytes data
Seq=100, 20 bytes data
Seq=92 timeout
ACK=100
Seq=100 timeout
ACK=120
Seq=92, 8 bytes data
ACK=120
time
premature timeout,
cumulative ACKs

25. TCP Connection Management: Three-way handshake
TCP uses three-way handshake for reliable connection establishment and termination
Host 1 sends segment with SYN bit set and random sequence number
Host 2 responds with segment with SYN bit set, acknowledgment to Host 1 and random sequence number
Host 1 responds with acknowledgment
TCP will retransmit lost segments
Random sequence numbers ensure synchronization between endpoints

26. Opening a connection Closing a connection Two-army Problem [그림 6.25]
[그림 6.26]
Two-army Problem
Computer Networks(3rd ed.)-Tanenbaum

27. TCP Connection Management (cont)
TCP server
lifecycle
TCP client
lifecycle