UDP dan TCP Risanuri Hidayat 7 November 2018 TCP.

Presentasi berjudul: "UDP dan TCP Risanuri Hidayat 7 November 2018 TCP."— Transcript presentasi:

1 UDP dan TCP Risanuri Hidayat 7 November 2018 TCP

2 Nomor Protokol di dalam IP
Keterangan 1 ICMP 2 Internet Group Management Prot 3 Gateway to Gateway Prot (GGP) 4 IP in IP 6 TCP 17 UDP 89 OSPF 7 November 2018 TCP

3 End-to-End Protocols Underlying best-effort network
drop messages re-orders messages delivers duplicate copies of a given message limits messages to some finite size delivers messages after an arbitrarily long delay Common end-to-end services guarantee message delivery deliver messages in the same order they are sent deliver at most one copy of each message support arbitrarily large messages support synchronization allow the receiver to flow control the sender support multiple application processes on each host 7 November 2018 TCP

4 UDP UDP = User Datagram Protocol, minimalistic transport protocol
Connection less, best effort (same best-effort service model as IP) messages of up to 64KB Tidak memerlukan setting connection Header sangat sederhana/simple dibanding TCP Source dan Destination port sama dengan TCP punya Datagram/paket/servis yang bisa bebas (unreliable) dan tidak urut (unordered) Tidak ada flow control, dan does not provide congestion control Endpoints identified by ports servers have well-known ports see /etc/services on Unix Optional checksum psuedo header + UDP header + data advantage over TCP: does not increase endto-end delay over IP application example: video/audio streaming 7 November 2018 TCP

5 UDP Port, menunjukkan layanan aplikasi (= TCP)
valid port numbers antara 0 – (16 bit) static port numbers adalah port yang telah terregister (reserved), dynamic port merupakan yang unregistered. Sesuai persetujuan, nilai port di atas adalah dynamic ports. (Aplikasi) Pengirim mengirim paket UDP melalui Source Port. (Aplikasi) penerima menerima (permintaan) aplikasi melalui Destination Port. SrcPort DstPort Length Checksum Data 16 31 7 November 2018 TCP

6 UDP Length, menunjukkan panjang header & data dalam octets. Ukuran maksimum secara teoritis adalah bytes (16 bit). Meskipun demikian, beberapa implementasi membatasi Length ini menjadi lebih kecil, kadang-kadang hanya sampai8192 bytes. Checksums, untuk check kesalahan. Pada UDP, checksummerupakan pilihan. Jika checksum ini tidak diperlukan maka nilai di-reset (nol semua). Pada TCP, checksums merupakan keharusan. 7 November 2018 TCP

7 Mengapa pakai UDP Packet oriented
Not a byte stream, packet integrity Tidak perlu set up koneksi, bisa lebih cepat Throughput lebih besar, karena UDP paket lebih mudah diproses di bagian Pengirim User tidak begitu peduli dengan reliabilitas (ketahanan paket) User ingin menggunakan Transport Protocol sendiri E.g. For video 7 November 2018 TCP

8 Port Need to decide which application gets which packets
Solution: map each socket to a port Client must know server’s port Separate 16-bit port address space for UDP and TCP (src IP, src port, dst IP, dst port) uniquely identifies TCP connection Well known ports (0-1023): everyone agrees which services run on these ports e.g., ssh:22, on UNIX, must be root to gain access to these ports (why?) ephemeral ports(most ): given to clients e.g. chatclient gets one of these EECS 122 Walrand 8 7 November 2018 TCP

9 TCP TCP = Transmission Control Protocol
TCP berada di atas IP, mengirim paket dengan fungsi-fungsi yang sangat berguna Streams. TCP data terorganisir sebagai stream of bytes, seperti file. Bentuk-bentuk datagram tidak akan kelihatan di sini. Reliable delivery. Sequence numbers digunakan untuk mengurutkan data-data yang dikirim dan diterima. TCP akan mengirim lagi suatu data yang rusak atau hilang. Network adaptation. TCP secara dinamis mempelajari tunda (delay) pengiriman akibat jaringan dan berusaha memaksimumkan throughput tanpa membebani jaringan tersebut. Flow control. TCP mengatur data buffers, dan koordinasi dengan trafik sehingga buffer-nya tidak pernah overflow. Pengirim yang cepat akan memperlambat kirimannya untuk menyesuaikan dengan penerima. 7 November 2018 TCP

10 TCP TCP merupakan end-to-end reliable connection, yang IP sendiri belum support Koneksi TCP sering dikenal dengan nama “socket” Socket dapat dianggap sebagai pipa penghubung bi-directional antara dua host. Untuk menyambung socket diperlukan IP penerima dan nomor port-nya Ports (bisa dianggap layanan) memungkinkan suatu host menghubungi host lain dengan lebih dari satu hubungan (lebih dari satu layanan) Nomor port sampai 1024 telah terpakai (Lihat di UNIX /etc/service) 7 November 2018 TCP

11 TCP Overview Full duplex
Transmission Control Protocol Connection-oriented Byte-stream app writes bytes TCP sends segments app reads bytes Full duplex Flow control: keep sender from overrunning receiver Congestion control: keep sender from overrunning network Application process W rite bytes TCP Send buffer Segment T ransmit segments Read Receive buffer … 7 November 2018 TCP

12 TCP Format 7 November 2018 TCP

13 TCP Format Source dan Destination port, merupakan aplikasi (layanan). Bersamaan dengan IP address disebut juga dengan Socket Seq. Number, nomor urutan. Sebagai contoh, jika SN suatu segment = 1343 dan segment tersebut berisi data 512 octets, maka segment selanjutnya akan mempunyai SN = 1856 (= ). Ack Number, menunjukkan next paket yang diharapkan diterima oleh destination. Jika Source menerima AN yang tidak cocok dengan next SN-nya (milik Source), maka Source tahu ada paket yang hilang (rusak) dan tahu juga paket mana yang hilang (rusak) tersebut. 7 November 2018 TCP

14 TCP Format Header length(4 bit), panjang Header dalam 32 bit
0, (6 bit) diset = 0 semua Flag (6 bit), digunakan untuk data flow dan connection control. Flag meliputi Urgent (URG), ACK, Push (PSH), Reset (RST), Synchronize (SYN), dan Final (FIN). Adv. Window, untuk flow control, menunjukkan berapa bytes yang akan dikirim setelah ACK diterima. Cheksum, meliputi Header dan Data Urgent pointer, menunjukkan posisi urgent data pada TCP paket (URG harus diset = 1) 7 November 2018 TCP

15 TCP Format Flag bits URG = Urgent pointer field in use
ACK = Indicates whether frame contains acknowledgement PSH = Data sudah di “pushed”. It should be delivered to higher layers right away. RST = Koneksi di-Reset (diulangi dari awal) SYN = Untuk memulai koneksi FIN = Untuk mengakhiri koneksi 7 November 2018 TCP

16 TCP Format Each connection identified with 4-tuple:
(SrcPort, SrcIPAddr, DsrPort, DstIPAddr) Sliding window + flow control acknowledgment, SequenceNum, AdvertisedWinow Flags SYN, FIN, RESET, PUSH, URG, ACK Checksum pseudo header + TCP header + data Sender Data (SequenceNum) Acknowledgment + AdvertisedWindow Receiver 7 November 2018 TCP

17 TCP Service Steps 3-Way Handshake State Diagram: 1 State Diagram: 2
Header Sliding Window Protocol 7 November 2018 TCP

18 TCP Service Connection Establishment
Data Transfer, Reliable byte stream delivery from (IPa, TCP Port 1) to (IPb, TCP Port 2) Indication if connection fails: Reset Terminate connection 7 November 2018 TCP

19 TCP Service Host A Host B Start Conn 3WH Data Transfer Close 1 Close 2
SYN (SN=x) SYN&ACK(SN=y, ACK=x) DATA(SN=x, ACK=y) Host A Host B ACK(ACK=x+y+1) Start Conn 3WH Data Transfer Close 1 Close 2 FIN FIN ACK 7 November 2018 TCP

20 Connection Establishment (CE)
SYN (SN=x) ACK&SYN(ACK=x+1 SN=y) (ACK=y+1 SN=x+1) Host A Host B Three Way Handshake 3WH connect() listen() accept() Goal: agree on a set of parameters: the start sequence number for each side Starting sequence numbers are random. 7 November 2018 TCP

21 CE (Frame 1) 7 November 2018 TCP Options (variable) Data
Checksum (55f4) SrcPort = 1427 (05 93) DstPort = 8080 (1f 90) 28 (70) 000000 000010 UrgPtr (00 00) AdvWindow=16384 (40 00) SequenceNum = 0 (9b 84 a7 24) Acknowledgment = 0 ( ) 4 10 16 31 7 November 2018 TCP

22 Connection Tear-Down Two types of connection tear-down:
Asymmetric Release: Either host may terminate the connection TCP: Symmetric Release: Both sides keep a unidirectional connection to the other For each connection, the source tears it down when no more packets will be sent 7 November 2018 TCP

23 Problem 1: Data lost In asymmetric tear-down, data may be lost:
7 November 2018 TCP

24 Problem 1: Data lost Partial solution:
Use 3-way handshake for connection tear-down Destination host starts a timer after it receives a disconnect request (DR) The destination finally releases the connection once its acknowledgement is also acknowledged If no return acknowledgement arrives within the timeout interval, the connection is disconnected 7 November 2018 TCP

25 Problem #2: Lost tear-down requests
What if all disconnect requests are lost? 7 November 2018 TCP

26 Problem #2: Lost tear-down requests
Solution: Require a host to close a connection if no packets have been received for a specified amount of time Hosts transmit keep-alive packets to keep a connection open when they have no data to send 7 November 2018 TCP

27 TCP Connection Tear-down
Two double handshakes: 7 November 2018 TCP

28 Flow and Error Control The transport layer, like the data link layer, must provide a flow-controlled and error-controlled link The data link layer is hop-by-hop (node-to-node), while the transport layer is end-to-end The same flow and error control protocols used in the data link layer may be used with the transport layer One additional concern: packet resequencing 7 November 2018 TCP

29 Sliding Window Revisited
Sending application LastByteWritten TCP LastByteSent LastByteAcked Receiving application LastByteRead LastByteRcvd NextByteExpected Sending side LastByteAcked < = LastByteSent LastByteSent < = LastByteWritten buffer bytes between LastByteAcked and LastByteWritten Receiving side LastByteRead < NextByteExpected NextByteExpected < = LastByteRcvd +1 buffer bytes between NextByteRead and LastByteRcvd 7 November 2018 TCP

30 Sliding Window with Out of Order Arrivals
Sender side window is unaffected by out of order reception of packets at the receiver Receiver side window, however, behaves differently when packets are able to arrive out of order New techniques required 7 November 2018 TCP

31 Sliding Window with Out of Order Arrivals
Procedure for receiver-side sliding window: Packets with sequence numbers outside the sliding window are discarded When a packet arrives out of order, place a mark by the packet’s sequence number in the window When the first packet in the sliding window arrives, adjust the start of the sliding window up to the next unmarked sequence number. Generate acknowledgements for each of the sequence numbers the sliding window just passed. 7 November 2018 TCP

32 TCP Flow Control TCP uses a modified version of the sliding window
In acknowledgements, TCP uses the “Window size” field to tell the sender how many bytes it may transmit TCP uses bytes, not packets, as sequence numbers 7 November 2018 TCP

33 TCP Flow Control Important information in TCP/IP packet headers
7 November 2018 TCP

34 TCP Flow Control 7 November 2018 TCP

35 TCP Flow Control Piggybacking: Allows more efficient bidirectional communication 7 November 2018 TCP

36 TCP Flow Control Problems
The Small Packet Problem Occurs when the source sends many small packets The Silly Window Syndrome Occurs when the destination reads a small number of bytes at a time from its buffer 7 November 2018 TCP

37 The Small Packet Problem (SPP)
Consider an interactive application where the source host sends each keystroke one at a time to the destination host Each keystroke is 1 byte. After adding TCP/IP overhead, a 41-byte packet is generated When the destination receives the packet, it returns a 40-byte acknowledgement packet When the destination removes the byte from its buffer, a 40-byte window update packet is sent Some applications echo the typed character back to the source, creating another 41-byte packet 7 November 2018 TCP

38 The Small Packet Problem (SPP)
7 November 2018 TCP

39 How TCP Solves the SPP Nagle’s Algorithm:
When data is sent one byte at a time, send only the first byte Buffer all remaining bytes until the first one is acknowledged After receiving the acknowledgement, send all the buffered bytes in one packet This algorithm reduces the amount of bandwidth required to support interactive applications 7 November 2018 TCP

40 Nagle’s Algorithm 7 November 2018 TCP

41 Problems with Nagle’s Algorithm
Works find if protocol is round trip oriented Send packet, wait for response What if protocol has several small packets? Type ahead with telnet over a slow link. X-windows data (plot point, draw-line) Socket option to turn off Nagle in Unix. 7 November 2018 TCP

42 Silly Window Syndrome (SWS)
Consider an application where the source sends in large blocks of data but the destination reads bytes from its buffer 1 byte at a time Each time the destination reads a byte from its buffer, it returns a window update to the source The source sees that it is only free to send 1 more byte so it sends a single byte This process repeats itself until all the data has been sent, 1 byte at a time 7 November 2018 TCP

43 Silly Window Syndrome (SWS)
7 November 2018 TCP

44 How TCP Solves the SWS Clark’s Solution:
Prevent the receiver application from reading only 1 byte from its TCP buffer The receiver application should only read from the TCP buffer when it has sufficient application buffer space to handle a larger chunk of data The sender may also help by refusing to send small data packets 7 November 2018 TCP

45 TCP Retransmission When a packet remains unacknowledged for a period of time, TCP assumes it is lost and retransmits it TCP tries to calculate the round trip time (RTT) for a packet and its acknowledgement From the RTT, TCP can guess how long it should wait before timing out RTT computation not part of the TCP specification! 7 November 2018 TCP

46 Round Trip Time (RTT) RTT = Time for packet to arrive at destination + Time for ACK to return from destination 7 November 2018 TCP

47 RTT 7 November 2018 TCP

48 Smoothing the RTT measurement
First, we must smooth the round trip time due to variations in delay within the network: SRTT = a SRTT + (1-a) RTTarriving ACK The smoothed round trip time (SRTT) weights previously received RTTs by the a parameter a is typically equal to 0.875 7 November 2018 TCP

49 Calculating the Retransmission Timeout Interval
The timeout value is then calculated by multiplying the smoothed RTT by some factor (greater than 1) called b Timeout = b ´ SRTT This coefficient of b is included to allow for some variation in the round trip times. 7 November 2018 TCP

50 Smoothing the RTT measurement Example
Initial SRTT = 1.50, a = 0.875, b = 4.0 7 November 2018 TCP

51 Problem with RTT Calculation
7 November 2018 TCP

52 Karn’s Algorithm Never update RTT measurements based on acknowledgements from retransmitted packets 7 November 2018 TCP

53 Another Problem with RTT Calculation
RTT measurements can sometimes fluctuate severely smoothed RTT (SRTT) is not a good reflection of round-trip time in these cases Solution: Use Jacobson/Karels algorithm: Error = RTT - SRTT SRTT = SRTT + (a ´ Error) Dev = Dev + [d ´ (|Error| - Dev)] Timeout = SRTT + (b ´ Dev) 7 November 2018 TCP

54 Jacobson/Karels Algorithm Example
Initial SRTT = 1.50, Dev = 0, a = 0.125, = 0.25, b = 4.0 Error = RTT - SRTT SRTT = SRTT + (a ´ Error) Dev = Dev + [d ´ (|Error| - Dev)] Timeout = SRTT + (b ´ Dev) 7 November 2018 TCP

55 TCP Congestion Control
Recall: Network layer is responsible for congestion control However, TCP/IP blurs the distinction In TCP/IP: the network layer (IP) simply handles routing and packet forwarding congestion control is done end-to-end by TCP 7 November 2018 TCP

56 TCP Congestion Window TCP introduces a second window, called the “congestion window” To determine how many bytes it may send, the sender takes the minimum of the receiver window and the congestion window Example: If the receiver window says the sender can transmit 8K, but the congestion window is only 4K, then the sender may only transmit 4K If the congestion window is 8K but the receiver window says the sender can transmit 4K, then the sender may only transmit 4K 7 November 2018 TCP

57 TCP Congestion Control
The TCP Congestion Control algorithm makes use of: – Slow Start – Congestion Avoidance (Linear Increase Thresholds) 7 November 2018 TCP

58 TCP Slow Start TCP defines the “maximum segment size” as the maximum size a TCP packet can be (including header) TCP Slow Start: Congestion window starts small, at 1 segment size Each time a transmitted segment is acknowledged, the congestion window is increased by one maximum segment size 7 November 2018 TCP

59 TCP Slow Start Congestion Window Size Event 1K 2K 4K 8K 16K
A sends 1 segment to B B ACKs the segment A sends 2 segments to B B ACKs both segments A sends 4 segments to B B ACKs all four segments A sends 8 segments to B B ACKs all eight segments … and so on 7 November 2018 TCP

60 TCP Slow Start Congestion window size grows exponentially (i.e. it keeps on doubling) Packet losses indicate congestion Packet losses are determined by using timers at the sender When a timeout occurs, the congestion window is reduced to one maximum segment size and everything starts over 7 November 2018 TCP

61 TCP Slow Start 7 November 2018 TCP

62 TCP Slow Start TCP Slow Start by itself is inefficient
Although the congestion window builds exponentially, it drops to 1 segment size every time a packet times out This leads to low throughput 7 November 2018 TCP

63 TCP Linear Increase Threshold
Establish a threshold at which the rate increase is linear instead of exponential to improve efficiency Algorithm: Start the threshold at 64K Start the congestion window size at 1 segment size Increase the congestion window size exponentially using slow start until the threshold is reached Once the threshold is passed, only increase the congestion window size by 1 segment size for each congestion window of data transmitted If a timeout occurs, reset the congestion window size to 1 segment and set threshold to 1/2 of MIN(sliding window, congestion window) 7 November 2018 TCP

64 TCP Linear Increase Threshold
Example: Maximum segment size = 1K 7 November 2018 TCP

65 TCP Fast Retransmit Another enhancement to TCP congestion control
Idea: When sender sees 3 duplicate ACKs, it assumes something went wrong The packet is immediately retransmitted instead of waiting for it to timeout 7 November 2018 TCP

66 TCP Fast Retransmit Example
7 November 2018 TCP

67 TCP Fast Recovery Yet another enhancement to TCP congestion control
Idea: Don’t do a slow start after a fast retransmit Instead, use this algorithm: Drop threshold to 1/2 of MIN(sliding window, congestion window) Set congestion window to threshold + 3 * MSS For each duplicate ACK (after the fast retransmit), increment congestion window by MSS When next non-duplicate ACK arrives, set congestion window equal to the threshold 7 November 2018 TCP

68 TCP Fast Recovery Example
7 November 2018 TCP

69 TCP recovery algorithm
Should know because: Behavior of TCP connections varies with timeout algorithm Many applications use TCP HTTP(Browsers), FTP, Chat rooms TCP timeouts can make the network seem slow, but really it’s the Timeout algorithm 7 November 2018 TCP