鏈路層定義了主機的身份，即MAC地址， 而網絡層定義了IP地址，明確了主機所在的網段，有了這兩個地址，數據包就從可以從一個主機發送到另一臺主機。但實際上數據包是從一個主機的某個應用程序發出，然後由對方主機的應用程序接收。而每臺電腦都有可能同時運行着很多個應用程序，所以當數據包被髮送到主機上以後，是無法確定哪個應用程序要接收這個包。
因此傳輸層引入了tcp/udp來解決這個問題，爲了給每個應用程序標識身份，協議定義了端口，同一個主機上的每個應用程序都需要指定唯一的端口號，並且規定網絡中傳輸的數據包必須加上端口信息。 這樣，當數據包到達主機以後，就可以根據端口號找到對應的應用程序了。
一：tcp的報頭
序號 ：用於對字節流進行編號，例如序號爲 301，表示第一個字節的編號爲 301，如果攜帶的數據長度爲 100 字節，那麼下一個報文段的序號應爲 401。
確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，因此 B 期望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認號就爲 701。
確認 ACK ：當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置 1。
同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，並要求釋放連接。
窗口 ：窗口值作爲接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。
二：tcp可靠傳輸的原因
超時重傳機制：在有限的時間能，接受不到接收方的ACK，發送發會重新傳遞；
連接管理：三次握手和四次揮手；
流量控制；
擁塞控制；
錯誤控制等手段。
三：三次握手
三次握手的原因：爲了防止已失效的鏈接請求報文突然又傳送到了服務端，因而產生錯誤。客戶端發出的連接請求報文並未丟失，而是在某個網絡節點長時間滯留了，以致延誤到鏈接釋放以後的某個時間纔到達Server。這是，Server誤以爲這是Client發出的一個新的鏈接請求，於是就向客戶端發送確認數據包，同意建立鏈接。若不採用“三次握手”，那麼只要Server發出確認數據包，新的鏈接就建立了。由client此時並未發出建立鏈接的請求，所以其不會理睬Server的確認，也不與Server通信；而這時Server一直在等待Client的請求，這樣Server就白白浪費了一定的資源。
三次握手出現的攻擊：
在三次握手過程中，Server發送SYN-ACK之後，收到Client的ACK之前的TCP連接稱爲半連接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，導致正常的SYN請求因爲隊列滿而被丟棄，從而引起網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV
四：四次揮手
四次揮手的原因：
因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，tcp是全雙工通信，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
需要等待一個時間計時器設置的時間 2MSL的原因：
在Client發送出最後的ACK回覆，但該ACK可能丟失。Server如果沒有收到 ACK，將不斷重複發送FIN片段。所以 Client 不能立即關閉，它必須確認 Server 接收到了該 ACK。Client 會在發送出 ACK 之後進入到 TIME_WAIT 狀態。 Client 會設置一個計時器，等待 2MSL 的時間。如果在該時間內再次收到 FIN，那麼 Client 會重發 ACK 並再次等待 2MSL。等待一段時間是爲了讓本連接持續時間內所產生的所有報文都從網絡中消失，使得下一個新的連接不會出現舊的連接請求報文。
五：tcp與udp的區別
tcp首部固定20B，udp固定8B.
tcp是可靠的單播傳遞，udp是不可靠的支持多播或廣播傳遞。
tcp有相應的控制，系統和內存開銷相對較大，Udp沒有擁塞流量控制。開銷較小。
tcp面向字節流（把應用層傳下來的報文看成字節流，把字節流組織成大小不等的數據塊）,udp面向報文（對於應用程序傳下來的報文不合並也不拆分，只是添加 UDP 首部）
六：tcp的狀態
七：流量控制（面向字節的滑動窗口）
通過滑動窗口實現流量控制。TCP支持全雙工的方式，因此在每個傳輸方向的接收方和發送發都有發送緩衝區和接受緩衝區。滑動窗口作用於緩衝區，實現對發送速度的流量控制。當發送方產生數據速度較慢或者接收方處理數據速度較慢會出現傻瓜窗口綜合症。窗口的大小是由接收方的確認報文進行指定的。
窗口是緩存的一部分，用來暫時存放字節流。發送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發送方自己的窗口大小，發送方根據這個值和其它信息設置自己的窗口大小。
發送窗口內的字節都允許被髮送，接收窗口內的字節都允許被接收。如果發送窗口左部的字節已經發送並且收到了確認，那麼就將發送窗口向右滑動一定距離，直到左部第一個字節不是已發送並且已確認的狀態；接收窗口的滑動類似，接收窗口左部字節已經發送確認並交付主機，就向右滑動接收窗口。
接收窗口只會對窗口內最後一個按序到達的字節進行確認，例如接收窗口已經收到的字節爲 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對字節 31 進行確認。發送方得到一個字節的確認之後，就知道這個字節之前的所有字節都已經被接收。
八：擁塞控制
流量控制是因爲接收方不能及時處理數據引發的機制。而擁塞控制是因爲在實際的傳輸過程中會經歷多個路由器和速率較慢的物理鏈路，它們的超載會引起數據傳輸的嚴重超時，從而進行擁塞控制。擁塞窗口大小是由發送方決定。擁塞控制一般是全局的，就是整個網絡狀況的控制。滑動窗口可以認爲是局部的，就是端到端的控制。實際發送的窗口大小爲滑動窗口和擁塞窗口的最小值。
TCP 主要通過四個算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。
慢開始和擁塞避免：
發送的最初執行慢開始，令 cwnd = 1，發送方只能發送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後發送方能夠發送的報文段數量爲：2、4、8 ...
注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發送方發送的速度增長速度過快，網絡擁塞的可能性也就更高。設置一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。
如果出現了超時，則令 ssthresh = cwnd / 2，然後重新執行慢開始。
快重傳和快恢復：
在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當發送對 M2 的確認。
在發送方，如果收到三個重複確認，那麼可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。
在這種情況下，只是丟失個別報文段，而不是網絡擁塞。因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免，使擁塞窗口緩慢地線性增長。
慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。慢開始 cwnd 設定爲 1，而快恢復 cwnd 設定爲 ssthresh。
用慢開始算法的原因：
主機開始發送數據報時，如果立即將大量的數據注入到網絡中，可能會出現網絡的擁塞。慢啓動算法就是在主機剛開始發送數據報的時候先探測一下網絡的狀況，如果網絡狀況良好，發送方每發送一次文段都能正確的接受確認報文段。那麼就從小到大的增加擁塞窗口的大小，即增加發送窗口的大小每一回都翻倍。當到達ssthresh的時候，就啓動擁塞避免算法，每次只在當前窗口上加1.到達cwnd，即發生網絡擁塞的時候，會將新的ssthresh設置爲cwnd的一半，且慢開始的起始值爲1，重新開始慢開始算法。
九：差錯控制
丟失或者是受損錯誤:這種情況下，接收方不會發送ACK，致使在發送方會出現超時重傳。
重複報文段錯誤：接受方直接丟棄重複報文字段。
失序報文字段：採用的延遲確認。即接收方將先接到的數據放在接收緩衝區，等到所有報文字段全部到達之後再向發送發發送ACK。