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 Connection less, best effort
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 Endpoints identified by ports servers have well-known ports see /etc/services on Unix Optional checksum psuedo header + UDP header + data 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 Checksum Length Data 16 31 7 November 2018 TCP

6 UDP Length, menunjukkan panjang data dalam octets. Jumlah bytes termasuk header dan data. 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 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

9 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

10 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

11 TCP Format 7 November 2018 TCP

12 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

13 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

14 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

15 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

16 Koneksi Transport layer bertanggung jawab terhadap layer di atasnya untuk sambungan end-to-end connection Diperlukan: Connection setup Connection tear-down 7 November 2018 TCP

17 Connection Establishment
Three-way Handshake 7 November 2018 TCP

18 Setting Up Koneksi Ketika suatu aplikasi di client ingin berhubungan dengan suatu aplikasi (layanan) di server (host lain), maka client tersebut harus men-set up sambungan Transport Layer ke layanan server tersebut Mengapa harus three-way handshake? Karena setting up a connection is not as easy as it seems (tidak semudah yang diduga) 7 November 2018 TCP

19 Setting Up Koneksi Contoh yang buruk (Naïve) :
Source mengirim suatu connection setup packet ke Destination Destination mengirim balik acknowledgment terhadap connection setup packet tadi, dan kemudian terjadi koneksi 7 November 2018 TCP

20 Naïve Dapat terjadi duplikasi connection request (CR) atau accept connection (AC) Anggap bahwa jaringan mempunyai tunda yang lama (karena ramai, congestion) 7 November 2018 TCP

21 Penyelesaian Dengan sequence number dan 3-way-handshake
Sequence number harus berulang pada suatu nilai yang besar untuk supaya yakin bahwa tidak ada sequence number yang sama 7 November 2018 TCP

22 3-way handshake: kasus 1 Successful Connection : 7 November 2018 TCP

23 3-way handshake: Kasus 2 Duplikasi CR 7 November 2018 TCP

24 2-way handshake Problem Duplikasi SYN 7 November 2018 TCP

25 3 way handshake Duplikasi CR dan ACK 7 November 2018 TCP

26 Fixing 2-way handshake Assume sender and receiver have same clock
Use time of clock to pick sequence numbers can reject based on clock value Assume receiver can remember all old sequence numbers can recall last SYN and reject 7 November 2018 TCP

27 3 way handshake: kasus 4 Simultanous Open 7 November 2018 TCP

28 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

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

30 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

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

32 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

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

34 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

35 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

36 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

37 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

38 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

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

40 TCP Flow Control 7 November 2018 TCP

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

42 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

43 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

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

45 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

46 Nagle’s Algorithm 7 November 2018 TCP

47 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

48 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

49 Silly Window Syndrome (SWS)
7 November 2018 TCP

50 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

51 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

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

53 RTT 7 November 2018 TCP

54 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

55 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

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

57 Problem with RTT Calculation
7 November 2018 TCP

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

59 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

60 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

61 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

62 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

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

64 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

65 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

66 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

67 TCP Slow Start 7 November 2018 TCP

68 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

69 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

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

71 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

72 TCP Fast Retransmit Example
7 November 2018 TCP

73 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

74 TCP Fast Recovery Example
7 November 2018 TCP

75 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