網路模組

1. 斷點續傳：

   實現原理：

   將一個檔案按照一定的規則人為的分割成多個小檔案，然後客戶端每次只上傳一個小檔案，伺服器接收到上傳過來的小檔案後根據一定的規則來組合這些小檔案。如果在上傳過程中出現網路中斷等意外情況，下次再次上傳時可以從已經上傳的部分繼續上傳，而不是重新上傳

   引數解釋：

   從 HTTP1.1 協議開始就已經支出獲取檔案的部分內容，斷點續傳技術就是利用 HTTP1.1 協議的這個特點在 Header 裡新增兩個引數來實現的。這兩個引數分別是客戶端請求時傳送的 Range 和伺服器返回資訊時返回的 Content-Range - Range，Range 用於指定第一個位元組和最後一個位元組的位置，格式如下：

   Range:(unit=first byte pos)-[last byte pos]

   Range 常用的格式有如下幾種情況：

   Range:bytes=0-1024 ，表示傳輸的是從開頭到第1024位元組的內容；

   Range:bytes=1025-2048 ，表示傳輸的是從第1025到2048位元組範圍的內容；

   Range:bytes=-2000 ，表示傳輸的是最後2000位元組的內容；Range:bytes=1024- ，表示傳輸的是從第1024位元組開始到檔案結束部分的內容；

   Range:bytes=0-0,-1 表示傳輸的是第一個和最後一個位元組 ；

   Range:bytes=1024-2048,2049-3096,3097-4096 ，表示傳輸的是多個位元組範圍。

   Content-Range Content-Range 用於響應帶有 Range 的請求。伺服器會將 Content-Range 新增在響應的頭部，格式如下：

   Content-Range:bytes(unit first byte pos)-[last byte pos]/[entity length]

   Content-Range:bytes 2048-4096/10240：2048-4096 表示當前傳送的資料範圍， 10240 表示檔案總大小。

   Note：

   1. 如果在客戶端請求報文頭中，對 Range 填入了錯誤的範圍值，伺服器會返回 416 狀態碼。

   2. 當使用斷點續傳的方式上傳下載軟體時 HTTP 響應頭將會變為: HTTP/1.1 206 Partial Content。

   3. 校驗：當伺服器端的檔案發生改變時，客戶端再次向服務端傳送斷點續傳請求時，資料肯定就會發生錯誤。這時我們可以利用 Last-Modified 來標識最後的修改時間，這樣就可以判斷伺服器上的檔案是否發生改變。

   4. 秒傳：秒傳利檔案的MD5，首先將檔案的MD5傳送個伺服器，伺服器傳輸過來的MD5判斷伺服器上是否存在相同型別的檔案，如果存在就將檔案複製一份，而不是本地上傳。

2. 三次握手：

   過程：

   1. 第⼀次握⼿： 客戶端給伺服器傳送⼀個 SYN 報⽂。
   2. 第⼆次握⼿： 伺服器收到 SYN 報⽂之後，會應答⼀個 SYN+ACK 報⽂。
   3. 第三次握⼿： 客戶端收到 SYN+ACK 報⽂之後，會迴應⼀個 ACK 報⽂。
   4. 伺服器收到 ACK 報⽂之後，三次握⼿建⽴完成。

   目的：

   1. 第⼀次握⼿： 客戶端傳送⽹絡包，服務端收到了。這樣服務端就能得出結論：客戶端的傳送能⼒、服務端的接收能⼒是正常的。

   2. 第⼆次握⼿： 服務端發包，客戶端收到了。這樣客戶端就能得出結論：服務端的接收、傳送能⼒，客戶端的接收、傳送能⼒是正常的。不過此時伺服器並不能確認客戶端的接收能⼒是否正常。

   3. 第三次握⼿： 客戶端發包，服務端收到了。這樣服務端就能得出結論：客戶端的接收、傳送能⼒正常，伺服器⾃⼰的傳送、接收能⼒也正常。

      因此，需要三次握⼿才能確認雙⽅的接收與傳送能⼒是否正常。

   作用：

   1. 確認雙⽅的接受能⼒、傳送能⼒是否正常。
   2. 指定⾃⼰的初始化序列號，為後⾯的可靠傳送做準備。
   3. 如果是 https 協議的話，三次握⼿這個過程，還會進⾏數字證書的驗證以及加密金鑰的⽣成到。

3. 四次揮手：

   過程：

   1. 第⼀次揮⼿： 客戶端傳送⼀個 FIN 報⽂，報⽂中會指定⼀個序列號。此時客戶端處於 CLOSED_WAIT1狀態。
   2. 第⼆次握⼿： 服務端收到 FIN 之後，會發送 ACK 報⽂，且把客戶端的序列號值 + 1 作為 ACK 報⽂的序列號值，表明已經收到客戶端的報⽂了，此時服務端處於CLOSE_WAIT2狀態。
   3. 第三次揮⼿： 如果服務端也想斷開連線了，和客戶端的第⼀次揮⼿⼀樣，發給 FIN 報⽂，且指定⼀個序列號。此時服務端處於 LAST_ACK 的狀態。
   4. 第四次揮⼿： 客戶端收到 FIN 之後，⼀樣傳送⼀個 ACK 報⽂作為應答，且把服務端的序列號值 + 1 作為⾃⼰ ACK 報⽂的序列號值，此時客戶端處於 TIME_WAIT 狀態。需要過⼀陣⼦以確保服務端收到⾃⼰的 ACK 報⽂之後才會進⼊ CLOSED 狀態
   5. 服務端收到 ACK 報⽂之後，就處於關閉連線了，處於 CLOSED 狀態。