淺談計算機網路（HTTP/HTTPS/TCP/UDP/IP）
前言
計算機網路是計算機專業很重要的一門課，課程中詳細闡述了兩臺計算機之間是如何進行通訊、如何保證通訊的可靠性、如何保證通訊的高效性等等內容，在日常coding中可能比較少關注到這方面，但是在真正遇到網路方面的問題無法解決時，瞭解計算機網路的原理卻是十分必要的。
OSI七層網路模型
-
OSI七層網路模型縮圖
-
自底向上理解七層網路模型
工程學科是不斷迭代的過程，因此七層協議大概是這麼進化來的。
-
物理層
物理層解決了兩臺機器之間相互通訊的問題，首先機器A傳送了一些位元流，機器B需要收到這些位元流，這就是物理層所做的事情。物理層主要定義了網路裝置的標準，例如介面的型別、機器的型別、網路的型別等。其傳輸的資料主要是bit流，也就是010101....這類資料，以電流強弱定義，也就是D/A or A/D轉換。物理層的分組
稱為bit。 -
資料鏈路層
在傳輸bit流的過程中，會產生錯傳、資料傳輸不完整的情況，資料鏈路層就應運而生。資料鏈路層主要定義資料格式化傳輸、以及如何控制對物理介質的訪問，通常還有錯誤控制和糾正，處理錯誤資料。這一層將分組稱為幀。
-
網路層
在資料傳輸的過程中，需要有資料傳送方和資料接收方，而且在網路越來越複雜的變化中，如何在多個節點中找到最佳路徑精準地找到接收方，這就是網路層需要做的事。網路層會將網路地址翻譯為對應的實體地址，然後通過計算，得出從節點A到節點B的最佳路徑，本層的協議是IP協議，在本層中將分組稱為資料報。
-
傳輸層
在網路層傳輸的過程中，會中斷好多次，所以需要把傳送的資訊切割為一個一個的Segment，分段傳輸，那麼其中一段傳送失敗了或出現錯誤了，要怎麼辦，是否需要重傳，這就是傳輸層需要乾的事。傳輸層保證了傳輸的質量，這層也被稱為OSI七層模型中最重要的一層，本層需要關注的協議為TCP/UDP協議。另外傳輸層會將資料報進行進一步切割，例如：以太坊無法接收大於1500Byte的資料報，於是傳輸層就將報文分割為多個報文段
，並按順序傳送，並且傳輸層是負責端到端的傳輸。 -
會話層
會話層的作用就是建立和管理應用程式之間的通訊，無需使用者過多地參與到TCP/IP協議中。
-
表示層
表示層可以幫助我們翻譯在不同型別網路上的資料，例如加密解密、轉換翻譯、壓縮解壓縮等。
-
應用層
應用層規定傳送方和接收方必須使用固定長度的訊息頭，並且封裝了各種的報文資訊，旨在使使用者更方便地應用網路中接收到的資料，該層需要關注的協議為HTTP協議，該層的分組稱為報文。
網路資料處理流程為，傳送方先自上而下封裝，接收方自下而上解封資料。而事實上OSI並沒有真正實現網路，而TCP/IP五層模型實際上是對OSI參考模型的實現。
-
TCP/IP協議族
-
傳輸控制協議（Transmission Control Protocol）簡介
- 面向連線的、可靠的、基於位元組流的傳輸層通訊協議
- 將應用層的資料流分割成報文段併傳送給目標節點的TCP層
- 報文段都有序號，對方收到則傳送ACK確認，未收到則重傳
-
TCP的報文頭
-
源埠：傳送方的埠號
-
目的埠：接收方的埠號
-
序號：TCP報文段的序號
-
確認序號：接收方接收到了序號為x的報文段，期待收到序號為x+1為起始的報文段。
-
資料偏移：報文段在整個報文中偏移的位元組量
-
保留域：備用區
-
標誌位：URG(緊急資訊)、ACK(確認標誌位)、PSH(為1則收到資訊收立即交給程式，無需再佇列中等待)、RST(重置標連線)、SYN(請求連線)、FIN(結束連線)
-
檢驗和：檢驗資料是否正確
-
TCP的三次握手
其一，主要是為了確認客戶機和伺服器同時具備傳送和接收的能力，第一次握手，伺服器確認了客戶機的傳送能力，第二次握手，客戶機確認了伺服器的接收能力和傳送能力，第三次握手，伺服器確認了客戶機的接收能力。
其二，是需要初始化seq的序號，以免在正式傳輸中出現亂序。
三次握手過程如下：
1.客戶機首先向伺服器傳送連線請求，此時SYN標誌位為1，且seq=x，x為一個大於等於1的正整數，此時伺服器為Listen狀態，客戶端處於SYN-SENT狀態。
2.伺服器收到了來自客戶機的請求，返回應答，此時SYN標誌位為1，ACK標誌位為1，ack=x+1（代表期望收到起始為seq=x+1的報文段），seq=y，此時伺服器處於SYN-RCVD狀態，客戶端處於ESTABLISHED狀態。
3.客戶機收到了伺服器返回的應答報文，於是傳送自己的應答報文，響應伺服器的應答，此時ACK標誌位為1，seq為x+1（響應ack需求），ack=y+1（表示期望從伺服器獲取y+1為起始的報文段），此時伺服器處於ESTABLISHED狀態。完成三次握手。
-
TCP的四次揮手
過程（假設由客戶端主動關閉）
1.客戶端傳送關閉連線請求，此時FIN標誌位為1，seq=u。
2.服務端返回應答報文，此時ACK標誌位為1，seq=v，ack=u+1（表示期望得到u+1為起始的報文段），等待一段時間，並且傳送剩餘資料（如果有的話）。
3.服務端傳送關閉連線請求，此時FIN標誌位為1，ACK標誌位為1，seq=w，ack=u+1。
4.客戶端返回應答請求，此時ACK標誌位為1，seq=u+1，ack=w+1。傳送過後服務端立即關閉連線，客戶端等待一段時間（2MSL，一分鐘左右），確定後續無資料傳送，則自行關閉連線。
>為什麼需要有2MSL的等待時間？
>1.確保對方收到自己的ACK，如果對方未收到ACK則會重發FIN請求，一來一回正好為2ML。
>2.避免新舊連線混淆。
>為什麼需要四次揮手？
>因為確保伺服器端和客戶端都有FIN和ACK。
複製程式碼-
SYN Flood洪泛攻擊
其原理是：例用三次握手的規則，在客戶機向伺服器傳送請求後，在伺服器傳送SYN-ACK後下線，伺服器則無法收到ACK確認，伺服器段則會不斷重試，重試間隔為1s,2s,4s,8s,16s,32s，在linux預設狀況下會等待63s，如果有大量的連線重複此過程，則會造成伺服器連線佇列耗盡，這就是洪泛攻擊的原理。
防護措施：linux下設定了TCP_SYN_Cookies引數，若為正常連線，客戶機發回SYN Cookie，如果為異常連線，就不發回，但也不會影響到連線佇列。
建立連線後客戶機突然出現故障：伺服器預設“保活機制”，會在一定時間內傳送請求，若幾次請求無應答，則將該客戶機標識為不可達客戶機。 -
TCP與UDP區別
首先先看UDP報文頭：
-
UDP的特點
1.面向非連線，傳輸速度快。
2.支援同時向多個客戶端傳輸資訊。
3.報文段報文頭只有8個位元組，額外開銷小。
4.吞吐量只受限於資料生成速率、傳輸速率以及機器效能。
5.盡最大努力交付，不保證可靠交付，不需要維持複雜的連線狀態表。
6.面向報文，不對應用程式提交的資訊進行拆分或合併。
結論：
1.TCP面向連線，UDP面向無連線
2.TCP可靠，UDP不可靠
3.TCP有序，UDP可能無序
4.TCP速度慢，UDP速度快
5.TCP重量級，UDP輕量級
複製程式碼-
TCP中的滑動視窗
滑動視窗是避免傳送方傳送過量資料導致接收方快取無法接收以至於資料丟失的問題，主要在報文頭的window欄位中，接收方會告訴傳送方自己的快取還可以接收多少資料，而傳送方可以根據這一資訊，調整自己將要傳送的資料。
1.LastByteAcked：最後被確認到的資料位置
2.LastByteSent：已傳送的資料的最後一個位元組位置
3.LastByteWritten：程式向滑動視窗寫入的資料位置
接收方視窗分為三段：
1.LastByteRead：最後被應用程式讀取到的資料（已經傳送ACK）位置
2.NextByteExpected：收到的但還未傳送ACK的資料位置
3.LastByteRcvd：已收到的最後一個位元組的位置。
計算方式
接收方還可處理量：AdvertisedWindow = MaxRcvBuffer（最大快取） - (LastByteRcvd-LastByteRead)
傳送方可傳送量：EffectiveWindow = AdvertiseWindow-(LastByteSent - LastByteAcked)
解讀：
接收方可處理量為 = 最大快取 - 已收到的報文段（已收到的最後一個位元組的位置-程式讀取到的資料的位置）
傳送方可傳送量 = 接收方可處理量 - 待確認量（傳送方最後傳送的位元組位置 - 傳送了並且已獲取確認的位置）
傳送方滑動視窗的四類資料：
2.已傳送但未得到確認的資料
3.未傳送但接收方同意傳送的資料
4.未傳送且接收方拒絕的資料
接收方滑動視窗三類資料
2.未接收但可以接收的資料
3.未接收且無法接收的資料
當接收方滑動視窗不足時，傳送方是不會移動自己的滑動視窗的，只有當傳送方的滑動視窗之前的所有資料都被確認，傳送方的滑動窗口才會向後移動，這也是TCP保證資料完整性的重要手段。
HTTP協議
-
HTTP簡介
HTTP：超文字傳輸協議
1.支援客戶/伺服器模式
2.簡單高效
3.靈活
4.無連線：限制每次連線只處理一個請求，但從HTTP1.1起，預設使用長連線。
5.無狀態
HTTP版本現在有常用的1.0和1.1，還有2.0，1.1在1.0的基礎上做了keep-alive長連線技術，而2.0雖然在各種思想上都顯得更加合理，但是1.1基本能滿足日常需求且更換2.0消耗大，所以2.0目前並沒有推廣開。 - HTTP請求報文
>請求方式 url 協議版本
>頭部欄位名:值
>......
>頭部欄位名:值
>請求正文
複製程式碼例如：
>POST /user HTTP/1.1 //請求行
>Host: www.baidu.com
>Content-Type: application/x-www-form-urlencoded
>Connection: Keep-Alive
>User-agent: Mozilla/5.0. //以上是首部行
>（此處必須有一空行） //空行分割header和請求內容
>name=world 請求體
複製程式碼-
HTTP報文頭
-
請求/響應的步驟 1.客戶端連線到Web伺服器
2.傳送HTTP請求
3.伺服器接受請求並返回HTTP響應
4.釋放TCP連線（如果是keep-alive則保持一段時間）
5.客戶端解析HTML內容 -
關於HTTP的面試題
1.在瀏覽器位址列鍵入URL，按下回車後經歷的流程。
答：首先要進行DNS解析，將訪問的域名解析為IP地址，解析是由近到遠的，首先在瀏覽器快取中尋找是否有對應的IP，如果沒有則進入系統快取，如果沒有則按照路由器快取->IPS伺服器快取->根域名快取->頂級域名伺服器快取，這樣一路查詢，直到找到了則停止查詢，直接返回。然後進行TCP連線，預設埠80，進行三次握手（可以簡單描述三次握手的流程），建立連線後傳送HTTP請求，伺服器處理請求並返回HTTP報文，瀏覽器解析並渲染頁面，最後連線結束。2.常見的HTTP狀態碼。 答：先分類。
1xx提示資訊--表示請求已接受，繼續處理
2xx表示成功連線
3xx重定向--要完成請求必須進行更進一步操作
4xx表示瀏覽器（客戶端）出現錯誤
5xx表示伺服器端出現錯誤
常見的HTTP狀態碼：
200 ok，成功連線
400 bad request(客戶端請求語法錯誤，伺服器無法理解)
401:未經授權
403:拒絕服務
404:Not Found
500內部伺服器錯誤
503：當前不能處理，一段時間後可能可以恢復正常。3.GET和POST請求的區別。
答：1.HTTP報文層面：GET請求資訊放在URL後（?XXX=XXX&XX=XXX），POST放在報文體，安全一些（但其實沒什麼區別，抓包可以直接抓到報文）
2.資料庫層面：GET符合冪等性（對資料庫一次或多次操作，結果是一致的）和安全性（對資料庫一次或多次操作，沒有改變資料庫中的資料），GET是做查詢操作的，不會改變資料庫中的資料。
3.POST插入，每次請求都有可能不一樣。
其他層面，GET可以被CDN快取，被儲存，在服務量巨大的環境下，又有大部分的資料是隻讀的，所以我們並不想讓伺服器完全處理，就可以使用GET請求，但POST不行,POST必須交由伺服器處理。4.Cookie和Session的區別
Cookie是客戶端解決方案，由伺服器發給客戶端的特殊資訊，以文字的形式存放在客戶端。
Cookie使用過程：
1.使用者向伺服器傳送個人識別資訊，伺服器也向客戶端傳送Cookie檔案。
2.客戶端再次傳送請求時，也會把cookie傳送回去。
3.服務端會獲取cookie從而生成與客戶端相對應的內容。
Session 服務端解決方案,Session是在伺服器上儲存的資訊。伺服器解析客戶端請求並操作SessionId，按需儲存狀態資訊。如果客戶端包含SessionId則直接使用，如果不包含則建立一個。
Session實現方式：
1.使用Cookie實現
客戶端向服務端傳送請求，服務端返回響應報文並SetCookie，Cookie中含有JSESSIONID-XXXXX，客戶端之後的每次請求都會攜帶這個Cookie，服務端根據這個Cookie中的Session提供響應的內容。
2.使用URL回寫實現
使用URL回寫即在URL地址中攜帶JSESSIONID這個引數。
Tomcat同時支援Cookie和URL回寫，預設使用Cookie，當瀏覽器拒絕Cookie時，則使用URL回寫的方式實現Session
區別：
Cookie是以檔案的形式儲存在客戶端，而Session是在伺服器端進行處理的，Session相對Cookie來說比較安全，因為Cookie儲存在客戶端，容易被修改，而Session存在於伺服器端，無法被修改，但Session會佔用伺服器資源，影響伺服器效能，如果考慮伺服器效能優先，則可以考慮多使用Cookie。 -
HTTP和HTTPS區別
HTTPS：超文字傳輸安全協議
HTTP:HTTP+TCP+IP
HTTPS:HTTP+(SSL OR TLS)+TCP+IP
要說HTTP和HTTPS的區別首先要提到SSL和加密方式。 -
SSL:Security-Sockets-Layer,安全套接層
SSL是為網路通訊提高安全及資料完整性的一種安全協議，是作業系統對外的API，SSL3.0後更名為TLS，採用身份驗證和資料加密保證網路通訊安全和資料的完整性。
-
加密的幾種形式
- 1.對稱加密 對稱加密是一種可以進行解密的加密方式，其特點就是，將一個資料按照一定過程加密，那麼按照這個過程的反過程一定可以將這個資料進行解密。其特點是效率高，但安全性低。
- 2.非對稱加密 非對稱加密的特點是加密使用的金鑰和解密使用的金鑰是不相同的，即，將一條資料按照一定的過程進行加密，按照這個過程的反過程並不能逆推回加密資料的源資料，而只能通過另一種特定的方式進行解密，這就是非對稱加密。非對稱加密的安全性高，但效率不如對稱加密。
- 3.Hash加密 Hash加密，將任意長度的資訊轉換為固定長度的值，其加密的資料是不可逆的，一般日常所用的加密方式是MD5方式。
- 4.數字簽名 在資訊後加一段Hash值，證明某個訊息或檔案時某人發出的，且可以證明資訊沒有被修改。
-
HTTPS使用的加密方式
HTTPS使用證書+各種加密方式共同加密
加密的三次握手過程：
1.瀏覽器將支援的加密演演算法資訊傳送給伺服器
2.伺服器選擇一套瀏覽器支援的加密方式，以證書的形式回發給瀏覽器。包含CA機構，公鑰，有效期，所有者等。
3.瀏覽器驗證證書的合法性，並結合證書公鑰，加密資訊傳送給伺服器。
4.伺服器使用私鑰解密，驗證hash，加密響應訊息回發瀏覽器
5.瀏覽器對響應訊息進行解密，並對訊息進行驗證，之後進行密文互動資料。 -
區別
HTTPS需要到CA申請證書，而HTTP不需要。
HTTPS的證書是需要收費的，HTTP不收費。
HTTPS預設埠為443，HTTP預設埠為80。
HTTPS為有狀態協議，HTTP為無狀態協議。
雖說HTTPS是安全協議，但是HTTPS也未必安全，在瀏覽器預設填充http:// 的情況下訪問https的網站，請求需要進行跳轉，這個過程中就有被劫持的風險。但可以使用HSTS優化（自行了解）。
Socket
-
Socket概念
Socket是對TCP/IP協議的抽象，是作業系統對外開放的介面，如果一定要按層次來理解Socket的話，Socket位於傳輸層之上，應用層之下。可以把它理解為一扇門，各種請求可以通過這扇門和和系統進行通訊。 -
Socket 通訊流程
-
Socket 通訊原理
我們知道，在程式間通訊我們可以通過管道、共享記憶體等等等等方式，但是無論使用哪一種方式，通訊的本質都是需要被通訊的物件有一個可以唯一標識的識別符號。在程式間通訊時，程式的識別符號為PID，而在網路通訊中，我們首先要使用IP標識主機，TCP+埠號標識程式。而埠號就相當於門牌號，Socket可以監聽某個埠來使該程式與某個請求進行互動。而Socket是基於Unix而生的，Unix奉行的宗旨就是，一切皆檔案，所以Socket的本質就是在讀寫特定的Socket檔案，以達到通訊的目的。
結語
通過上文的敘述，可以大概瞭解OSI七層網路模型的“各司其職”、瞭解TCP/IP協議族、還有三次握手四次揮手的整個過程、瞭解洪泛攻擊的原理、TCP/UDP的區別以及TCP中擁塞控制之滑動視窗，還瞭解了HTTP協議以及HTTP安全協議——HTTPS，還稍微談到了點Socket。 計算機網路是一門大的學科，上面所說的也不過百分之二三，寥寥而已。但是基本可以滿足日常開發所需。
本文圖片來自網路，侵刪。
歡迎大家訪問我的個人部落格：Object's Blog