計算機網絡
三次握手和四次揮手
1） 請求端發送一個syn段指明客戶打算連接的服務器的端口，以及初始序號。
2） 服務器發回包含服務器的初始序號的syn報文段，同時將確認序號設置爲客戶的序號加1.
3） 客戶必須將確認序號設置爲服務器的序號加1以對服務器的syn報文段進行確認
TCP提供了連接的一端在結束它的發送後還能接收來自另一端數據的能力。這就是所謂的半關閉。只有很少的應用程序使用它。
假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了 "，但是如果你還有數據沒有發送完成，則不必急着關閉Socket，可以繼續發送數據。所以你先發送ACK，" 告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉連接了 "。Client端收到FIN報文後，" 就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳 。“，Server端收到ACK後，" 就知道可以斷開連接了 "。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
TCP協議
1. TCP提供一種面向連接的、可靠的字節流服務。
2. 提供可靠性的方法：
TCP按報文段發送；
有用於超時重傳的定時器；
確認是否收到確認；
保持它首部和數據的檢驗和
可能需要重新排序；
能夠丟棄重複數據；
流量控制；
3. TCP首部：16位源端口號，16位目的端口號，32位序號，32位確認序號，4位首部長度，16位窗口大小、檢驗和（發端計算和存儲，並由收端進行驗證）、緊急指針等
4. TCP的數據流分爲兩種交互數據流和成塊數據流。按字節計算，成塊數據與交互數據的比例約爲90%和10%；按分組數量計算，各佔一半。
5. 交互數據流的擁塞控制：Nagle算法：該算法要求一個TCP連接上最多只能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發送其他的小分組。相反，TCP收集這些少量的分組，並在確認到達之前時以一個分組的方式發出去。
6. TCP的滑動窗口協議：
窗口合攏：窗口左邊沿向右邊沿靠近，發生在數據被髮送和確認時；
窗口張開：窗口右邊沿向右移動時將允許發送更多的數據，發生在另一端的接受進程讀取已經確認的數據並釋放了TCP的接受緩存時；
7. 擁塞控制：慢啓動、擁塞避免、快速恢復、快速重傳。
擁塞窗口：發送方取擁塞窗口與通告窗口中的最小值作爲發送上限。擁塞窗口是發送方使用的流量控制，而通告窗口則是接收方使用的流量控制。
慢啓動：該算法通過觀察到新分組進入網絡的速率應該與另一端返回確認的速率相同而進行工作。發送方開始時發送一個報文段，然後等待ACK。當收到該ACK時，擁塞窗口從1增加爲2，即可以發送兩個報文段。
8. TCP管理4個不同的定時器：
重傳定時器使用於當希望收到另一端的確認；
堅持定時器使窗口大小信息保持不斷流動；
保活定時器可檢測到一個空閒連接的另一端合何時崩潰或重啓；
2MSL定時器測量一個鏈接處於TIME_WAIT狀態的時間；
9. 擁塞避免算法是一種處理丟失分組地方法；（擁塞避免和慢啓動算法維持兩個變量：一個擁塞窗口CWND和一個慢啓動門限ssthresh
10. 快速重傳與快速恢復算法：如果一連串收到3個或3個以上的重複ACK，就非常可能是一個報文段丟失了。於是我們就重傳丟失的數據報文段，而無需等待超時定時器溢出。這就是快速重傳算法。接下來執行的是不是慢啓動算法而是擁塞避免算法。這就是快速恢復算法。
TCP粘包
一般所謂的TCP粘包是在一次接收數據不能完全地體現一個完整的消息數據。
1: 如果利用tcp每次發送數據，就與對方建立連接，然後雙方發送完一段數據後，就關閉連接，這樣就不會出現粘包問題
（因爲只有一種包結構,類似於http協議）。關閉連接主要要雙方都發送close連接（參考tcp關閉協議）。如：A需要發送一段字符串給B，那麼A與B建立連接，然後發送雙方都默認好的協議字符如"hello give me sth abour yourself"，然後B收到報文後，就將緩衝區數據接收,然後關閉連接，這樣粘包問題不用考慮到，因爲大家都知道是發送一段字符。
2： 如果發送數據無結構，如文件傳輸，這樣發送方只管發送，接收方只管接收存儲就ok，也不用考慮粘包
3：如果雙方建立連接，需要在連接後一段時間內發送不同結構數據，如連接後，有好幾種結構：
1)"hello give me sth abour yourself"
2)"Don't give me sth abour yourself"
那這樣的話，如果發送方連續發送這個兩個包出去，接收方一次接收可能會是"hello give me sth abour yourselfDon't give me sth abour yourself"這樣接收方就傻了，到底是要幹嘛？不知道，因爲協議沒有規定這麼詭異的字符串，所以要處理把它分包，怎麼分也需要雙方組織一個比較好的包結構，所以一般可能會在頭加一個數據長度之類的包，以確保接收。
三.粘包出現原因：在流傳輸中出現，UDP不會出現粘包，因爲它有消息邊界(參考Windows網絡編程)
1發送端需要等緩衝區滿才發送出去，造成粘包
2接收方不及時接收緩衝區的包，造成多個包接收
HTTP協議和HTTPS協議
http:端口號80
https：端口號443
HTTPS（SecureHypertext Transfer Protocol）安全超文本傳輸協議：
它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息，它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作爲HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使用40 位關鍵字作爲RC4流加密算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。總的來說，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議要比http協議安全。
在URL前加https://前綴表明是用SSL加密的，你的電腦與服務器之間收發的信息傳輸將更加安全。 Web服務器啓用SSL需要獲得一個服務器證書並將該證書與要使用SSL的服務器綁定。
HTTPS和HTTP的區別：
https協議需要到ca申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,後者是443。
http的連接很簡單,是無狀態的。
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全。
http狀態碼3xx 4xx 5xx分別是啥
重定向，客戶端錯誤，服務器端錯誤
1xx（臨時響應）
表示臨時響應並需要請求者繼續執行操作的狀態代碼。
代碼說明
100（繼續） 請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其餘部分。
101（切換協議） 請求者已要求服務器切換協議，服務器已確認並準備切換。
2xx（成功）
表示成功處理了請求的狀態代碼。
代碼說明
200（成功） 服務器已成功處理了請求。 通常，這表示服務器提供了請求的網頁。
201（已創建） 請求成功並且服務器創建了新的資源。
202（已接受） 服務器已接受請求，但尚未處理。
203（非授權信息） 服務器已成功處理了請求，但返回的信息可能來自另一來源。
204（無內容） 服務器成功處理了請求，但沒有返回任何內容。
205（重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206（部分內容） 服務器成功處理了部分GET請求。
3xx（重定向）
表示要完成請求，需要進一步操作。通常，這些狀態代碼用來重定向。
代碼說明
300（多種選擇） 針對請求，服務器可執行多種操作。 服務器可根據請求者(user agent)選擇一項操作，或提供操作列表供請求者選擇。
301（永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對GET或HEAD請求的響應）時，會自動將請求者轉到新位置。
302（臨時移動） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
303（查看其他位置） 請求者應當對不同的位置使用單獨的GET請求來檢索響應時，服務器返回此代碼。
304（未修改） 自從上次請求後，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
305（使用代理） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。
307（臨時重定向） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
4xx（請求錯誤）
這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
代碼說明
400（錯誤請求） 服務器不理解請求的語法。
401（未授權） 請求要求身份驗證。 對於需要登錄的網頁，服務器可能返回此響應。
403（禁止） 服務器拒絕請求。
404（未找到） 服務器找不到請求的網頁。
405（方法禁用） 禁用請求中指定的方法。
406（不接受） 無法使用請求的內容特性響應請求的網頁。
407（需要代理授權） 此狀態代碼與401（未授權）類似，但指定請求者應當授權使用代理。
408（請求超時） 服務器等候請求時發生超時。
409（衝突） 服務器在完成請求時發生衝突。 服務器必須在響應中包含有關衝突的信息。
410（已刪除） 如果請求的資源已永久刪除，服務器就會返回此響應。
411（需要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。
412（未滿足前提條件） 服務器未滿足請求者在請求中設置的其中一個前提條件。
413（請求實體過大） 服務器無法處理請求，因爲請求實體過大，超出服務器的處理能力。
414（請求的URI過長） 請求的URI（通常爲網址）過長，服務器無法處理。
415（不支持的媒體類型） 請求的格式不受請求頁面的支持。
416（請求範圍不符合要求） 如果頁面無法提供請求的範圍，則服務器會返回此狀態代碼。
417（未滿足期望值） 服務器未滿足"期望"請求標頭字段的要求。
5xx（服務器錯誤）
這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。這些錯誤可能是服務器本身的錯誤，而不是請求出錯。
代碼說明
500（服務器內部錯誤） 服務器遇到錯誤，無法完成請求。
501（尚未實施） 服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。
502（錯誤網關） 服務器作爲網關或代理，從上游服務器收到無效響應。
503（服務不可用） 服務器目前無法使用（由於超載或停機維護）。 通常，這只是暫時狀態。
504（網關超時） 服務器作爲網關或代理，但是沒有及時從上游服務器收到請求。
505（HTTP版本不受支持） 服務器不支持請求中所用的HTTP協議版本。
HTTP請求頭和返回頭
HTTP請求頭
ACCEPT,ACCEPT-ENCODING,ACCEPT-LANGUAGE,CONNECTION,COOKIE,HOST,USER-AGENT,REFERER,
HTTP返回頭
CONNECTION,CONTENT-ENCODING,CONTENT-TYPE,DATE,SET-COOKIE,TRANSFER-ENCODING,VARY
S ocket模型
1. socket函數
爲了執行網絡I/O，一個進程必須做的第一件事情就是調用socket函數，指定期望的通信協議類型。
2. connect函數
用socket函數來建立與TCP服務器的連接。
3. bind函數把一個本地協議地址賦予一個套接字。對於國際網協議，協議地址是32位的IPV4地址或128位的IPV6地址與16位的TCP或UDP端口的組合。
4. L isten函數：當socket函數創建一個套接字時，它被假設爲一個主動套接字，也就是說，它是一個將調用connect發起連接的客戶套接字。 L isten函數把一個未連接的套接字轉換成一個被動套接字，指示內核應接受指向該套接字的連接請求。根據TCP狀態轉換圖，調用listen導致套接字從closed轉換到listen狀態。
5. A ccept函數：accept函數由TCP服務器調用，用於從已完成連接隊列隊頭返回下一個已完成連接（圖4-7）。如果已完成連接隊列爲空，那麼進程被投入睡眠。
6. C lose函數：關閉套接字，終止TCP連接。
SYN攻擊
SYN攻擊屬於DOS攻擊的一種，它利用TCP協議缺陷，通過發送大量的半連接請求，耗費CPU和內存資源。SYN攻擊除了能影響主機外，還可以危害路由器、防火牆等網絡系統，事實上SYN攻擊並不管目標是什麼系統，只要這些系統打開TCP服務就可以實施。從上圖可看到，服務器接收到連接請求（syn=j），將此信息加入未連接隊列，併發送請求包給客戶（syn=k,ack=j+1），此時進入SYN_RECV狀態。當服務器未收到客戶端的確認包時，重發請求包，一直到超時，纔將此條目從未連接隊列刪除。配合IP欺騙，SYN攻擊能達到很好的效果，通常，客戶端在短時間內僞造大量不存在的IP地址，向服務器不斷地發送syn包，服務器回覆確認包，並等待客戶的確認，由於源地址是不存在的，服務器需要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，正常的SYN請求被丟棄，目標系統運行緩慢，嚴重者引起網絡堵塞甚至系統癱瘓。
【問題1】爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
答：因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
【問題2】爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
C lient端主動打開連接、主動關閉連接的情況：
C lient主動打開，SYN_SENT狀態，發送SYN J，服務器收到進入SYN_RCVD狀態，SYN K,ack J+1，客戶端進入established狀態，發送ack K+1，服務器端進入ESTABLISHED狀態。
客戶端FIN_WAIT1狀態，發送FIN M，服務器端進入CLOSE_WAIT狀態，發送ack M+1，客戶端FIN_WAIT2狀態，當服務器端發送完LAST_ACK後，服務器端發送FIN N,客戶端進入TIME_WAIT狀態（在這個狀態停留2MSL的時間，MSL：報文段最長生存時間），發送ackN+1.服務器端closed狀態。