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

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

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

TCP/IP 응용 계층 구조

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

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

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

TCP 계층 PDU 구조

TCP/IP 계층의 주소 구조

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

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

TCP와 UDP의 비교

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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