-
Notifications
You must be signed in to change notification settings - Fork 1
/
mod1-09.html
497 lines (459 loc) · 25.1 KB
/
mod1-09.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Advanced Networking - Module 1 Chapter 9 - Transport Layer</title>
<meta name="description" content="Abilitante alle certificazioni Cisco CCENT e CCNA">
<meta name="author" content="Hacklab Cosenza">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/hlcs.css" id="theme">
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section>
<h1>Advanced Networking</h1>
<h2>Routing & Switching:</h2>
<h2>Introduction to Networks</h2>
<h3>Chapter 9: Transport Layer</h3>
<small><a href="http://hlcs.it">Hacklab Cosenza</a> / Centro di Ricerca su Tecnologia e Innovazione</small>
</section>
<section>
<h2>The OSI L4: Transport</h2>
<p>The transport layer provides the means for <strong>process-to-process connectivity</strong> through the network. Its functions are:</p>
<ul>
<li><strong>Tracking the individual communications</strong> initiated by applications on sender and receiver hosts.</li>
<li><strong>Segmenting and reassembling data streams</strong> for better manageability.</li>
<li><strong>Identifying the application</strong> each particular stream belongs to.</li>
</ul>
<p>L2: link-to-link; L3: end-to-end; L4: <strong><u>process-to-process</u></strong>.</p>
</section>
<section>
<section>
<h2>Segmentation and Multiplexing</h2>
<img src="http://i.imgur.com/PLD8Zq4.jpg" width="65%">
<p>With <strong>no segmentation</strong>, communications are poorly managed: the bigger it is, the longer it occupies the channel and the higher is the risk of an error resulting in retransmissions and wasted bandwidth.</p>
</section>
<section>
<h2>Segmentation and Multiplexing</h2>
<img src="http://i.imgur.com/IThNYoO.jpg" width="65%">
<p>By segmenting communications, we allow for <strong><em>multiplexing</em></strong> them on a single channel, which means combining <u>multiple data streams into a single signal</u>. This greatly increases manageability and efficiency.</p>
</section>
</section>
<section>
<section>
<h2>TCP and UDP</h2>
<img src="http://i.imgur.com/5knyqyg.png">
<p>TCP/IP protocol suite provides 2 very different alternative as transport layer protocols: the <strong>TCP (<em>Transmission Control Protocol</em>)</strong> and <strong>UDP (<em>User Datagram Protocol</em>)</strong>.</p>
<p><u>TCP is the reliable</u>, fully-featured alternative, while <u>UDP is the low-overhead</u> and simpler choice.</p>
</section>
<section>
<h2>TCP and UDP</h2>
<p>TCP is considered a <u>reliable</u> transport protocol because it uses <strong>acknowledged delivery</strong>. It performs all the basic Layer 4 functions seen before, plus:</p>
<ul>
<li>It establishes a <strong>connection</strong> before doing anything.</li>
<li>It <strong>sequences</strong> (order) the data.</li>
<li><strong>it acknowledges received data</strong>.</li>
<li><strong>it retransmits any unacknowledged data</strong>.</li>
<li>It manages the <strong>ongoing connection flow</strong> (<em>TCP is stateful</em>).</li>
</ul>
<p><u>UDP doesn't do any of this</u>, it just provides the basic L4 functions: then <strong>a subset of these could be implemented by the application using UDP</strong>, avoiding the overhead of TCP.</p>
</section>
</section>
<section>
<h2>TCP or UDP?</h2>
<p><u>There is no single answer</u>. Both are valid protocols. It depends on the <strong>application requirements</strong> to use one, the other, or even both. If, for example:</p>
<ul>
<li><strong>all data must be received</strong> before any of it is useful;</li>
<li>the application <strong>can't process unordered</strong> data;</li>
</ul>
<p>like email client or web browsers, then <u>TCP is the right choice</u>. If, on the other hand, for an application:</p>
<ul>
<li>the <strong>fastest possibile</strong> communication is needed;</li>
<li>Partial data loss is acceptable, but <strong>delays are not</strong>;</li>
</ul>
<p><u>UDP might be the better choice</u>, like it is for streaming audiovideo, simple request-reply workloads and most real-time applications.</p>
</section>
<section>
<section>
<h2>How Do TCP and UDP track data streams?</h2>
<p>Both use <strong><u>port addressing</u></strong>, which means they assign a <strong>port number</strong> to specific applications and services to the client (source port) and the server (destination port).</p>
<ul>
<li><strong>Source Port</strong>: randomly generated by the client application to identify a specific application conversation, it is <strong>used as a return address</strong> by the server.</li>
<li><strong>Destination Port</strong>: it's placed in the header by the client, either by configuration or because it's a well-known and established port associated to the requested service.</li>
<li>They are <strong>used in reverse</strong> by the server for the replies.</li>
</ul>
</section>
<section>
<h2>Well-Known Ports and Ranges</h2>
<small>
<table>
<tr>
<td><strong>Port Number</strong></td>
<td><strong>Protocol</strong></td>
<td><strong>Application</strong></td>
</tr>
<tr>
<td>20, 21</td>
<td>TCP</td>
<td>FTP</td>
</tr>
<tr>
<td>22</td>
<td>TCP</td>
<td>SSH</td>
</tr>
<tr>
<td>23</td>
<td>TCP</td>
<td>Telnet</td>
</tr>
<tr>
<td>25</td>
<td>TCP</td>
<td>SMTP</td>
</tr>
<tr>
<td>53</td>
<td>UDP, TCP</td>
<td>DNS</td>
</tr>
<tr>
<td>67, 68</td>
<td>UDP</td>
<td>DHCP</td>
</tr>
<tr>
<td>69</td>
<td>UDP</td>
<td>TFTP</td>
</tr>
<tr>
<td>80</td>
<td>TCP</td>
<td>HTTP</td>
</tr>
<tr>
<td>110</td>
<td>TCP</td>
<td>POP3</td>
</tr>
<tr>
<td>161</td>
<td>UDP</td>
<td>SNMP</td>
</tr>
<tr>
<td>443</td>
<td>TCP</td>
<td>SSL</td>
</tr>
</table>
</small>
<ul>
<li><strong>Well-known</strong>: 0 - 1023, port registered by IANA to be used for important services.</li>
<li><strong>Registered</strong>: 1024 - 49151, port assigned by IANA through requests.</li>
<li><strong>Dynamic/Private</strong>: 49152 - 65535, dynamically assigned by clients when a connection is made.</li>
</ul>
</section>
<section>
<h2>Sockets</h2>
<p>What uniquely identifies <u>each communicating process on any single host</u> is <strong>the combination of transport layer port numbers, and network layer IP address</strong>.</p>
<p>This combination is called a <strong>socket</strong>.</p>
<p>A <strong>socket pair</strong> is the coupled source and destination IP addresses and port numbers, that <strong>uniquely identifies <u>specific conversations</u></strong> between the two hosts.</p>
<p>A socket is commonly expressed as <code>address:port</code>.</p>
<ul>
<li>213.92.16.101:80 (web server)</li>
<li>188.165.254.131:25 (smtp mail server)</li>
</ul>
</section>
<section>
<h2>Active connections on a host</h2>
<pre><code class="bash">stefanauss@barney:~$ netstat -tun
Connessioni Internet attive (senza server)
Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato
tcp 28 0 10.87.23.2:47290 91.189.92.23:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:44180 91.189.92.23:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:44183 91.189.92.23:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:56717 91.189.92.11:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:59277 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:52056 78.98.23.227:26050 ESTABLISHED
tcp 28 0 10.87.1.134:45380 91.189.92.10:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:43491 188.165.254.131:143 CLOSE_WAIT
tcp 28 0 10.87.23.2:59269 91.189.92.11:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:53684 91.189.92.10:443 CLOSE_WAIT
tcp 1 0 10.87.23.2:56509 91.189.94.25:80 CLOSE_WAIT
tcp 0 0 10.87.23.2:58865 79.50.31.156:30774 ESTABLISHED
tcp 0 0 10.87.23.2:55113 95.244.65.27:50607 ESTABLISHED
tcp 28 0 10.87.1.134:55560 91.189.92.11:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:56463 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 127.0.0.1:45740 127.0.0.1:54099 ESTABLISHED
tcp 28 0 10.87.23.2:49183 91.189.92.24:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:53679 74.125.195.16:993 ESTABLISHED
tcp 0 0 10.87.23.2:60076 188.125.69.63:993 CLOSE_WAIT
tcp 0 0 10.87.23.2:41260 157.56.53.40:12350 ESTABLISHED
tcp 0 0 10.87.23.2:40233 108.160.167.167:80 ESTABLISHED
tcp 0 0 127.0.0.1:35363 127.0.0.1:39587 ESTABLISHED
tcp 0 0 10.87.23.2:48389 188.125.69.43:993 CLOSE_WAIT
tcp 28 0 10.87.23.2:59283 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:56480 173.194.116.0:443 ESTABLISHED
tcp 0 0 10.87.23.2:43863 188.165.254.131:143 ESTABLISHED
tcp 0 0 10.87.23.2:53654 74.125.206.16:993 ESTABLISHED
tcp 1 0 127.0.0.1:38608 127.0.0.1:56675 CLOSE_WAIT
tcp 0 0 127.0.0.1:45749 127.0.0.1:54099 ESTABLISHED
tcp 0 0 10.87.23.2:43492 188.165.254.131:143 CLOSE_WAIT
tcp 28 0 10.87.1.134:46308 91.189.92.10:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:59275 91.189.92.11:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:44182 91.189.92.23:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:58640 198.199.65.215:443 ESTABLISHED
tcp 28 0 10.87.1.134:46305 91.189.92.10:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:46561 91.189.92.10:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:53676 91.189.92.10:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:47293 91.189.92.23:443 CLOSE_WAIT
tcp 0 0 127.0.0.1:54099 127.0.0.1:45743 ESTABLISHED
tcp 28 0 10.87.1.134:43930 91.189.92.23:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:55527 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 127.0.0.1:54099 127.0.0.1:45740 ESTABLISHED
tcp 0 0 10.87.23.2:48015 173.194.78.189:443 ESTABLISHED
tcp 28 0 10.87.1.134:56479 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:43482 188.165.254.131:143 ESTABLISHED
tcp 28 0 10.87.1.134:46307 91.189.92.10:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:47628 173.194.78.189:443 TIME_WAIT
tcp 28 0 10.87.1.134:46559 91.189.92.10:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:49181 91.189.92.24:443 CLOSE_WAIT
tcp 0 0 127.0.0.1:45745 127.0.0.1:54099 ESTABLISHED
tcp 0 0 10.87.23.2:60740 78.141.75.220:22466 ESTABLISHED
tcp 0 0 127.0.0.1:45743 127.0.0.1:54099 ESTABLISHED
tcp 0 0 10.87.23.2:40371 79.51.51.216:37192 ESTABLISHED
tcp 0 0 127.0.0.1:45744 127.0.0.1:54099 ESTABLISHED
tcp 0 0 127.0.0.1:39587 127.0.0.1:35363 ESTABLISHED
tcp 0 0 10.87.23.2:43490 188.165.254.131:143 CLOSE_WAIT
tcp 28 0 10.87.23.2:47294 91.189.92.23:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:54872 91.189.92.24:443 CLOSE_WAIT
tcp 28 0 10.87.1.134:46323 91.189.92.10:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:36275 173.194.112.226:443 ESTABLISHED
tcp 28 0 10.87.1.134:44181 91.189.92.23:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:51836 74.125.195.16:993 ESTABLISHED
tcp 28 0 10.87.23.2:53682 91.189.92.10:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:43838 188.165.254.131:143 ESTABLISHED
tcp 28 0 10.87.1.134:46321 91.189.92.10:443 CLOSE_WAIT
tcp 0 0 10.87.23.2:36595 157.56.193.37:443 ESTABLISHED
tcp 0 0 10.87.23.2:40480 157.55.235.165:40013 ESTABLISHED
tcp 28 0 10.87.1.134:56481 91.189.92.11:443 CLOSE_WAIT
tcp 28 0 10.87.23.2:59267 91.189.92.11:443 CLOSE_WAIT
tcp 0 0 127.0.0.1:54099 127.0.0.1:45745 ESTABLISHED
tcp 0 0 127.0.0.1:54099 127.0.0.1:45744 ESTABLISHED
tcp 1 0 10.87.23.2:60475 91.198.174.208:80 CLOSE_WAIT
tcp 1 0 127.0.0.1:38608 127.0.0.1:56677 CLOSE_WAIT
tcp 0 0 127.0.0.1:54099 127.0.0.1:45749 ESTABLISHED
tcp 0 0 10.87.23.2:56117 87.6.187.238:64540 ESTABLISHED
tcp 0 0 10.87.23.2:53650 74.125.206.16:993 ESTABLISHED
tcp6 1 0 ::1:44104 ::1:631 CLOSE_WAIT</code></pre>
<p>By removing the "n" option, <strong>domain names are used in place of IP addresses</strong> where possible, making it <strong>easier to identify the purpose</strong> of the connection.</p>
</section>
</section>
<section>
<section>
<h2>TCP Header</h2>
<img src="http://i.imgur.com/zac7kmY.jpg" style="width: 110%;">
</section>
<section>
<h2>TCP Header</h2>
<ul>
<li><strong>Sequence number</strong> (32 bits) - Used for data reassembly.
<li><strong>Acknowledgement number</strong> (32 bits) - Indicates the data that has been received.</li>
<li><strong>Header length</strong> (4 bits) - Known as <em>data offset</em>. Indicates the length of the TCP segment header.</li>
<li><strong>Reserved</strong> (6 bits) - This field is reserved for the future.</li>
<li><strong>Control bits</strong> (6 bits) - Includes bit codes, or flags, that indicate the purpose and function of the TCP segment.</li>
<li><strong>Window size</strong> (16 bits) - Indicates the number of segments that can be accepted at one time.</li>
<li><strong>Checksum</strong> (16 bits) - Error checking for header and data.</li>
<li><strong>Urgent</strong> (16 bits) - Indicates if data is urgent.</li>
</ul>
</section>
<section>
<h2>TCP Flags/Control Bits</h2>
<ul>
<li><strong>URG</strong> (1 bit) – the Urgent pointer field is significant.</li>
<li><strong>ACK</strong> (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.</li>
<li><strong>PSH</strong> (1 bit) – Push function. Asks to push the buffered data to the receiving application.</li>
<li><strong>RST</strong> (1 bit) – Reset the connection.</li>
<li><strong>SYN</strong> (1 bit) – Synchronize sequence numbers. Only the first segment sent from each end should have it set. Some flags and fields change meaning, and could be valid or not, based on whether this flag is set or clear.</li>
<li><strong>FIN</strong> (1 bit) – No more data from sender.</li>
</ul>
</section>
</section>
<section>
<section>
<h2>UDP Header</h2>
<img src="http://i.imgur.com/cHTDUXN.png">
<p>Looking at the UDP header, the overhead TCP introduces for carrying its functions should be really clear.</p>
<p>UDP Payload is called a <em>datagram</em>.</p>
</section>
</section>
<section>
<section>
<h2>TCP 3-Way Handshake</h2>
<p>It's the process through which <strong>TCP establishes a connection</strong> before any data can be exchanged. How?</p>
<ol>
<li>The initiating client requests a client-to-server communication session with the server.</li>
<li>The server acknowledges the client-to-server session and requests a server-to-client session.</li>
<li>The initiating client acknowledges the server-to-client session.</li>
</ol>
<p>The 3-way handshake sets up the <strong><u>2 one-way data streams</u></strong> that form a full-duplex TCP conversation. It relies on <strong>SYN, ACK flags and sequence and acknowledgment numbers</strong>.</p>
</section>
<section>
<h2>TCP 3-Way Handshake</h2>
<img src="http://i.imgur.com/zy76Rp5.gif" style="width: 700px;">
</section>
<section>
<h2>TCP 3-Way Handshake</h2>
<img src="http://i.imgur.com/ghaC3KL.png" style="width: 800px;">
</section>
</section>
<section>
<section>
<h2>TCP 3-Way Handshake - Step 1 (SYN)</h2>
<p>A TCP client begins the 3-way handshake by
sending a segment with:</p>
<ul>
<li><strong>SYN control flag set to 1</strong>, to validate the ISN.</li>
<li>an <em>Initial sequence number</em> <strong>(ISN)</strong> that is <u>randomly chosen</u> (A) and that begins to track data flow.</li>
</ul>
<p>The ISN in the header of each segment will be <strong>increased by one for each byte of data</strong> sent from the client to the server as the data conversation continues.</p>
<p><strong>In Wireshark sequence numbers are relative</strong> to ISN and always starts as 0.</p>
</section>
<section>
<h2>TCP 3-Way Handshake - Step 2 (SYN ACK)</h2>
<ul>
<li>The <strong>server replies with SYN control bit set to 1</strong>, to validate server's ISN.</li>
<li>The <strong>server replies with ACK control bit set to 1</strong>, to validate server's acknowledge number.</li>
<li>The acknowledgment number is set to Client ISN + 1 (A+1), as if it's saying <em>this is the next byte i'm expecting to receive from you...</em></li>
<li>The new sequence number that the server chooses for the segment is another random number (B).</li>
</ul>
</section>
<section>
<h2>TCP 3-Way Handshake - Step 3 (ACK)</h2>
<ul>
<li>Finally, <strong>the client sends an ACK back</strong> to the server.</li>
<li>The sequence number is set according to the received acknowledgement value (A+1).</li>
<li>and the acknowledgement number is set according to the received sequence number (B+1).</li>
</ul>
<p>Data conversation is now in place, and the <strong>client and the server exchange (one's) data and ACKs (of the other host's data)</strong>.</p>
</section>
</section>
<section>
<section>
<h2>TCP Connection Termination</h2>
<p>The connection termination phase uses a 4-way handshake, that <strong>each side can initiate independently</strong> (if they do it at the same time, it becomes a <u>3-way termination handshake</u>).</p>
<ol>
<li>When the "client" has no more data to send in the stream, it <strong>sends a segment with the FIN flag set</strong>.</li>
<li>The "server" sends <strong>an ACK to acknowledge the receipt of the FIN</strong> to terminate the session from client to server.</li>
<li>The <strong>server keeps sending data until (and if) it has them, then it sends a FIN</strong> to the client, to terminate the server to client session.</li>
<li>The <strong>client responds with an ACK to acknowledge the FIN</strong> from the server.</li>
</ol>
</section>
<section>
<h2>TCP Connection Termination</h2>
<h3>4-Way Handshake</h3>
<img src="http://i.imgur.com/a3dWHUc.png" width="60%" height="60%">
</section>
</section>
<!--
<section>
<h1>Practice</h1>
<h2>TCP 3-Way and 4-Way Handshake</h2>
<h2>with Wireshark</h2>
</section>
-->
<section>
<h2>ACK and SEQ numbers</h2>
<p>The <strong>SEQ number indicates the relative number of bytes</strong> that have been transmitted in this session.</p>
<p>TCP uses the ACK number sent back to the source to indicate <u>the next byte that the receiver expects to receive</u>. This is called <strong><em>expectational acknowledgement</em></strong>.</p>
<p>The sending host is expected to send a segment that uses <strong>a new sequence number that is equal to the ACK number</strong>.</p>
<p>SEQ and ACK numbers are being <strong>exchanged in both directions</strong>.</p>
</section>
<section>
<h2>TCP Combined ACK</h2>
<p>To <strong>reduce the overhead</strong> of the acknowledgements, multiple segments of data can be sent and <strong>acknowledged with a single TCP message</strong> in the opposite direction.</p>
<p>This acknowledgement <strong>contains an ACK number based on the total number of bytes received</strong> in the session.</p>
<p><u>Example</u>: starting with a sequence number of 2000, if 10 segments of 1000 bytes each were received, an ACK number of 12001 would be returned to the source.</p>
</section>
<section>
<h2>TCP Retransmissions</h2>
<p><u>TCP acknowledges data that has received in a contiguous sequence of bytes</u> (no holes in SEQ numbers).</p>
<p>When TCP at the source host has not received an acknowledgement <strong>after a predetermined amount of time, it returns to the last ACK number received</strong> and <u>retransmits the data from that point forward</u>.</p>
<p>The retransmission process is not specified by the TCP's RFC, but is left up to the particular implementation of TCP. Some are implementing <strong>SACK</strong> (<em>Selective ACK</em>).</p>
</section>
<section>
<section>
<h2>Flow Control and Window Size</h2>
<p>Flow control helps the reliability of TCP transmissions by <strong>adjusting the rate of data flow</strong> between source and destination in a given session.</p>
<p>The TCP header includes a 16-bit field, the <strong><em>window size</em>. This is the number of bytes</strong> that the destination of a TCP session is able to <strong>accept before requiring an acknowledgment</strong>.</p>
<p>The initial window size is agreed upon during the 3-way handshake, and then <strong>renegotiated as needed</strong> (<em>sliding window</em>).</p>
</section>
<section>
<h2>TCP Flow Control</h2>
<h3>Window Size Management</h3>
<img src="http://i.imgur.com/zapGiTx.gif" style="width: 600px;">
</section>
<section>
<h2>TCP Flow Control</h2>
<h3>Window Size + Combined ACK</h3>
<img src="http://i.imgur.com/Amb71xv.gif" style="width: 600px;">
</section>
</section>
<!--
<section>
<h1>Practice</h1>
<h2>UDP with Wireshark</h2>
</section>
-->
<section>
<h1>End of Lesson</h1>
</section>
<!-- Port Numbers as identifications
Stateful vs stateless protocol
-->
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
// More info https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
transition: 'slide', // none/fade/slide/convex/concave/zoom
// More info https://github.com/hakimel/reveal.js#dependencies
dependencies: [
{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/zoom-js/zoom.js', async: true },
{ src: 'plugin/notes/notes.js', async: true }
]
});
</script>
</body>
</html>