TCP，IP通訊協議
一個 http 請求，在整個網路中的請求過程
當應用程式用T C P傳送資料時，資料被送入協議棧中， 然後逐個通過每一層直到被當作一串位元流送入網路。其 中每一層對收到的資料都要增加一些首部資訊
當目的主機收到一個乙太網資料幀時，資料就開始從協議 棧中由底向上升，同時去掉各層協議加上的報文首部。每 層協議盒都要去檢查報文首部中的協議標識，以確定接收 資料的上層協議。這個過程稱作分用
為什麼有了MAC層還要走IP層呢？ mac地址和裝置的生產者，批 次，日期之類的關聯起來，知道一個裝置的mac，並不能 在網路中將資料傳送給它，除非它和傳送方在同一個網 絡內。所以要實現機器之間的通訊，還需要有ip地址，ip地址表達的是當前機器在網路中的位置。通過ip層的定址，我們 能知道按何種路徑在全世界任意兩臺Internet上的的機器 間傳輸資料。
IP 協議和 TCP/UDP 協議
什麼是協議
協議相當於兩個需要通過網路通訊的程式達成的一種約定， 它規定了報文的交換方式和包含的意義。比如（HTTP）為 瞭解決在伺服器之間傳遞超文字物件的問題，這些超文字 物件在伺服器中建立和儲存，並由 Web 瀏覽器進行可視 化，完成使用者對遠端內容的感知和體驗 。
什麼是 IP 協議
T C P和U D P是兩種最為著名的傳輸層協議，他們都是 使用I P作為網路層協議。IP協議提供了一組資料報文服 務，每組分組報文都是由網路獨立處理和分發，每個IP報文必須包 含一個目的地址的欄位；IP協議只是一個“盡力而為”的協議，在網 絡傳輸過程中，可能會發生報文丟失、報文順序打亂，重 復發送的情況。IP協議層之上的傳輸層，提供了兩種可以 選擇的協議，TCP、UPD。這兩種協議都是建立在IP層所 提供的服務基礎上，根據應用程式的不同需求選擇不同方 式的傳輸。
TCP/IP
TCP協議能夠檢測和恢復IP層提供的主機到主機的通訊 中可能發生的報文丟失、重複及其他錯誤。TCP 提供了一 個可信賴的位元組流通道，這樣應用程式就不需要考慮這些 問題。同時，TCP協議是一種面向連線的協議，在使用TCP 進行通訊之前，兩個應用程式之間需要建立一個TCP連線， 而這個連線又涉及到兩臺電腦需要完成握手訊息的交換。
UDP/IP
UDP協議不會對IP層產生的錯誤進行修復，而是簡單的 擴充套件了 IP 協議“盡力而為”的資料報文服務，使他能夠在應 用程式之間工作，而不是在主機之間工作，因此使用UDP 協議必須要考慮到報文丟失，順序混亂的問題 。
TCP 是如何做到可靠傳輸的？
建立可靠的連結
由於TCP協議是一種可信的傳輸協議，所以在傳輸之 前，需要通過三次握手建立一個連線，所謂的三次握手， 就是在建立TCP連結時，需要客戶端和服務端總共傳送3 個包來確認連線的建立
TCP 四次揮手協議
四次揮手錶示 TCP 斷開連線的時候,需要客戶端和服務端 總共傳送 4 個包以確認連線的斷開；客戶端或伺服器均可 主動發起揮手動作(因為 TCP 是一個全雙工協議)，在 socket 程式設計中，任何一方執行 close() 操作即可產生揮手。
為什麼連線的時候是三次握手，關閉的時候卻是四次 握手？ 三次握手是因為當 Server 端收到 Client 端的 SYN 連線請求報文後，可以直接傳送SYN+ACK 報文。其中 ACK報文是用來應答的， SYN 報文是用來同步的。但是關閉連 接時，當Server 端收到 FIN 報文時，很可能並不會立即 關閉 SOCKET （ 因 為 可 能 還 有 消 息 沒 處 理 完 ）， 所 以只 能 先回復一個 ACK 報文，告訴 Client 端， " 你發的 FIN 報文 我收到了 " 。只有等到我 Se rver 端所有的報文都發送完 了，我才能傳送 FIN 報文，因此不能一起傳送。故需要四 步握手。
資料傳輸過程的流量控制和確認機制
建立可靠連線以後，就開始進行資料傳輸了。在通訊過程 中，最重要的是資料包，也就是協議傳輸的資料。如果數 據的傳送與接收過程當中出現收方來不及接收的情況，這 時就需要對發方進行控制以免資料丟失。利用滑動視窗機 制可以很方便的在TCP連線上實現對傳送方的流量控 制。TCP的視窗單位是位元組，不是報文段，傳送方的傳送 視窗不能超過接收方給出的接收視窗的數值。
滑動視窗協議
滑動視窗（Sliding window）是一種流量控制技術。早期的 網路通訊中，通訊雙方不會考慮網路的擁擠情況直接傳送 資料。由於大家不知道網路擁塞狀況，同時傳送資料，導 致中間節點阻塞掉包，誰也發不了資料，所以就有了滑動視窗機制來解決此問題；傳送和接受方都會維護一個數據 幀的序列，這個序列被稱作視窗 。
傳送和接受方都會維護一個數據幀的序列， 這個序列被稱作視窗。傳送方的視窗大小由接受方確定，
目的在於控制傳送速度，以免接受方的快取不夠大，而導 致溢位，同時控制流量也可以避免網路擁塞。下面圖中的 4,5,6
號資料幀已經被髮送出去，但是 未收到關聯的 ACK ， 7,8,9 幀則是等待發送。可以看出傳送端的視窗大 小為 6
，這是由接受端告知的。此時如果傳送端收到 4 號 ACK ，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴 展，此時視窗就向前 “ 滑動了 ”
，即資料幀 10 也可以被髮 送。
傳送視窗
就是傳送端允許連續傳送的幀的序號表。 傳送端可以不等待應答而連續傳送的最大幀數稱為傳送窗 口的尺寸。
接收視窗
接收方允許接收的幀的序號表，凡落在 接收視窗內的幀， 接收方都必須處理，落在接收視窗外的幀被丟棄。 接收方每次允許接收的幀數稱為接收視窗的尺寸。
線上滑動視窗演示功能
https://media.pearsoncmg.com/aw/ecs_kurose_compnetw
ork_7/cw/content/interactiveanimations/selective-repeat
protocol/index.html
應用層的 tcp/udp 通訊 是基於socket和DatagramSocket的 。
通訊的效能問題
正常的通訊過程如下(BIO)
我們發現TCP響應伺服器一次只能處理一個客戶端請 求，當一個客戶端向一個已經被其他客戶端佔用的伺服器 傳送連線請求時，雖然在連線建立後可以向服務端傳送數 據，但是在服務端處理完之前的請求之前，卻不會對新的 客戶端做出響應，這種型別的伺服器稱為“迭代伺服器”。 迭代伺服器是按照順序處理客戶端請求，也就是服務端必 須要處理完前一個請求才能對下一個客戶端的請求進行響 應。但是在實際應用中，我們不能接收這樣的處理方式。 所以我們需要一種方法可以獨立處理每一個連線，並且他 們之間不會相互干擾。而Java提供的多執行緒技術剛好滿足這個需求，這個機制使得伺服器能夠方便處理多個客戶 端的請求。
如何提高效能
TCP 協議的通訊過程
對於 TCP 通訊來說，每個 TCP Socket 的核心中都有一個 傳送緩衝區和一個接收緩衝區，TCP 的全雙工的工作模式 及 TCP 的滑動視窗就是依賴於這兩個獨立的 Buffer 和該 Buffer的填充狀態。 接收緩衝區把資料快取到核心，若應用程序一直沒有呼叫 Socket 的 read 方法進行讀取，那麼該資料會一直被快取 在接收緩衝區內。不管程序是否讀取Socket，對端發來的 資料都會經過核心接收並快取到 Socket 的核心接收緩衝 區。 read所要做的工作，就是把核心接收緩衝區中的資料複製 到應用層使用者的Buffer裡。 程序呼叫Socket的send傳送資料的時候，一般情況下是 將資料從應用層使用者的 Buffer 裡複製到 Socket 的核心發 送緩衝區，然後send就會在上層返回。換句話說，send返 回時，資料不一定會被髮送到對端。
Socket 的接收緩衝區被 TCP 用來快取網路上收到的資料， 一直儲存到應用程序讀走為止。如果應用程序一直沒有讀 取，那麼Buffer滿了以後，出現的情況是：通知對端TCP 協議中的視窗關閉，保證TCP接收緩衝區不會移除，保證 了TCP是可靠傳輸的。如果對方無視視窗大小發出了超過 視窗大小的資料，那麼接收方會把這些資料丟棄。
如何使用非阻塞提高效能？
非阻塞要解決的就是I/O執行緒與Socket解耦的問題，因 此，它引入了事件機制來達到解耦的目的。我們可以認為 NIO底層中存在一個I/O排程執行緒，它不斷的掃描每個 Socket的緩衝區，當發現寫入緩衝區為空的時候，它會 產生一個Socket可寫事件，此時程式就可以把資料寫入 到Socket中。如果一次寫不完，就等待下一次的可寫事 件通知；反之，當發現緩衝區裡有資料的時候，它會產生 一個Socket可讀事件，程式收到這個通知事件就可以從 Socket讀取資料了。
關於 NIO
實際上基於傳統的BIO模型，一個請求一個執行緒 的方式，如果要涉及到上千個客戶端訪問時，會產生很多 的問題，比如擴充套件性、系統資源開銷等等。所以我們需要 一種方法來輪詢一組客戶端，來查詢哪個連線需要提供服 務，這個就是我們講的“NIO”。
緩衝區
在NIO中，所有資料都是用緩衝區處理，在讀取資料的時 候，它是直接讀到緩衝區中，在寫如資料的時候，也是寫 到緩衝區。任何時候訪問NIO中的資料，都是通過緩衝區 進行的操作 。
通道
Channel 通道，就像一個自來水管一樣，可以通過它讀取 和寫入資料，Channel是全雙工的，所以資料是雙向流動。
多路複用
多路複用器Selector，是NIO的基礎，多路複用器提供選 擇已經就緒的任務的能力，簡單來說，Selector 會不斷輪 詢註冊上的Channel，如果某個Channel上面有新的TCP 連線接入、讀、寫事件，這個 Channel 就處於就緒狀態，會被Selector輪詢出來，然後通過SelectionKey可以獲取 就緒的Channel進行I/O操作；一個多路複用器可以同時 輪詢多個 Channel。通過這個機制可以接入成千上萬的客 戶端。
組播協議 Multicast
對於某些資訊，多個接受者都可能感興趣的時候，那麼我 們應該怎麼解決呢？我們可以向每個接受者單播一個數據 副本，但是如果這樣的話，效率會低；而且同樣的資料發 送多次，浪費頻寬。 解決方案是，我們可以把複製資料包的工作交給網路來做， 而不是由傳送者負責。這樣無論是多少客戶端，都沒問題。
有兩種分發型別，廣播（broadcast）和多播（multicast）。
廣播：網路中的所有主機都會接收到一份資料副本
廣播是主機向子網內所有主機發送訊息，子網內所有主機都能收到來自某臺主機的廣播資訊，屬於點對所有點的通訊。廣播意味著網路向子網每一個主機都投遞一份資料包，不論這些主機是否樂意接收該資料包;
多播
多播是主機向一組主機發送資訊，存在於某個組的所有主機都可以接收到訊息，屬於點對多點的通訊。
多播：訊息只發送給一個多播地址，網路只是將資料分發 給哪些想要接收發送到該多播地址的資料的主機。
總的來說，要實現這個功能，只有UDP是最合適的 。