經常使用的熟知端口號
| 應用程序 | FTP | TFTP | TELNET | SMTP | DNS | HTTP | SSH | MYSQL |
| 熟知端口 | 21,20 | 69 | 23 | 25 | 53 | 80 | 22 | 3306 |
| 傳輸層協議 | TCP | UDP | TCP | TCP | UDP | TCP |
TCP
- 源端口和目的端口，各佔2個字節，分別寫入源端口和目的端口；
- 序號，佔4個字節，TCP鏈接中傳送的字節流中的每一個字節都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的數據共有100字段，顯然下一個報文段（若是還有的話）的數據序號應該從401開始；
- 確認號，佔4個字節，是指望收到對方下一個報文的第一個數據字節的序號。例如，B收到了A發送過來的報文，其序列號字段是501，而數據長度是200字節，這代表B正確的收到了A發送的到序號700爲止的數據。所以，B指望收到A的下一個數據序號是701，因而B在發送給A的確認報文段中把確認號置爲701；
- 數據偏移，佔4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠；
- 保留，佔6位，保留從此使用，但目前應都位0；
- 緊急URG，當URG=1，代表緊急指針字段有效。告訴系統此報文段中有緊急數據；
- 確認ACK，僅當ACK=1時，確認號字段纔有效。TCP規定，在鏈接創建後全部報文的傳輸都必須把ACK置1；
- 推送PSH，當兩個應用進程進行交互式通訊時，有時在一端的應用進程但願在鍵入一個命令後當即就能收到對方的響應，這時候就將PSH=1；
- 復位RST，當RST=1，代表TCP鏈接中出現嚴重差錯，必須釋放鏈接，而後再從新創建鏈接；
- 同步SYN，在鏈接創建時用來同步序號。當SYN=1，ACK=0，代表是鏈接請求報文，若贊成鏈接，則響應報文中應該使SYN=1，ACK=1；
- 終止FIN，用來釋放鏈接。當FIN=1，代表此報文的發送方的數據已經發送完畢，而且要求釋放；
- 窗口，佔2字節，指的是通知接收方，發送本報文你須要有多大的空間來接受；
- 檢驗和，佔2字節，校驗首部和數據這兩部分；
- 緊急指針，佔2字節，指出本報文段中的緊急數據的字節數；
- 選項，長度可變，定義一些其餘的可選的參數。
TCP鏈接的創建（三次握手）
最開始的時候客戶端和服務器都是處於CLOSED狀態。主動打開鏈接的爲客戶端，被動打開鏈接的是服務器。服務器
- TCP服務器進程先建立傳輸控制塊TCB，時刻準備接受客戶進程的鏈接請求，此時服務器就進入了LISTEN（監聽）狀態；
- TCP客戶進程也是先建立傳輸控制塊TCB，而後向服務器發出鏈接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。
- TCP服務器收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。
- TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。
- 當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始通訊了。
爲何TCP客戶端最後還要發送一次確認呢？
一句話，主要防止已經失效的鏈接請求報文忽然又傳送到了服務器，從而產生錯誤。網絡
若是使用的是兩次握手創建鏈接，假設有這樣一種場景，客戶端發送了第一個請求鏈接而且沒有丟失，只是由於在網絡結點中滯留的時間太長了，因爲TCP的客戶端遲遲沒有收到確認報文，覺得服務器沒有收到，此時從新向服務器發送這條報文，此後客戶端和服務器通過兩次握手完成鏈接，傳輸數據，而後關閉鏈接。此時此前滯留的那一次請求鏈接，網絡通暢了到達了服務器，這個報文本該是失效的，可是，兩次握手的機制將會讓客戶端和服務器再次創建鏈接，這將致使沒必要要的錯誤和資源的浪費。spa
若是採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文而且回覆了確認報文，可是客戶端不會再次發出確認。因爲服務器收不到確認，就知道客戶端並無請求鏈接。3d
TCP鏈接的釋放（四次揮手）
數據傳輸完畢後，雙方均可釋放鏈接。最開始的時候，客戶端和服務器都是處於ESTABLISHED狀態，而後客戶端主動關閉，服務器被動關閉。指針
- 客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
- 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
- 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
- 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
- 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。
TCP和UDP的區別blog
1、TCP（面向鏈接如打電話要先撥號創建鏈接），創建TCP鏈接需通過三次握手,釋放TCP鏈接需通過四次揮手;UDP是無鏈接的，即發送數據以前不須要創建鏈接進程
2、TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付ci
Tcp經過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。資源
3、UDP具備較好的實時性，工做效率比TCP高，適用於對高速傳輸和實時性有較高的通訊或廣播通訊。同步
4.每一條TCP鏈接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通訊
5、TCP對系統資源要求較多，UDP對系統資源要求較少。