網絡協議TCP/UDP
從瀏覽器輸入一個url中間經歷的進程
- 中間涉及了那些過程
- 包含了那些網絡協議
- 每個協議都幹了什麼
1：解析是那個協議->判斷是ip地址還是域名->DNS緩存（瀏覽器緩存、host文件）->DNS查詢->TCP握手->HTTP請求->反向代理nginx->uwsgi/gunicorn->web-app響應->TCP揮手
2：這個過程會從應用層（Http協議、Https協議）-傳輸層（TCP協議）-網絡層（ARP協議，IP協議，ICMP協議）-數據鏈路層-物理層。
3：應用層：
- Http協議：HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據
- Https協議：基本沿用http協議，只是在http和tcp之中加多一層tls/ssl協議，位於應用層和傳輸層的安全套接層，
https主要有幾個特性，機密性、完整性、身份認證和不可否認。機密性由對稱加密、非對稱加密或者兩個混合一起、完整性靠摘要算法。身份認證和不可否認就靠數字簽名（私鑰加密，公鑰再解密）
傳輸層：
- TCP協議：提供全雙工通信，確保可靠交付的服務
網絡層：
注：ARP協議爲IP協議提供服務，IP協議爲ICMP協議提供服務
- ARP協議：通過廣播把IP地址解析成mac地址
- IP協議：IP可以根據數據包包頭中包括的目的地址將數據包傳送到目的地址，在此過程中IP負責選擇傳送的道路，這種選擇道路稱爲路由功能。
- ICMP協議:確認IP包是否成功到達目標地址,報告在發送過程中IP包被丟棄的原因
TCP三次握手
- 客戶端發送一個SYN包給服務端
- 服務端返回一個SYN/ACK應答報，表示服務器接收連接
- 客戶端再發會一個ACK應答包，並進入連接狀態（ESTABLISHED）
- 服務端收到這個應答包後也進入連接狀態
TCP狀態
- LISTENING：監聽狀態
- ESTABLISHED：表示建立連接，正在通信
- CLOSE_WAIT：對方主動關閉連接或者網絡異常導致連接中斷，這時我方的狀態會變成CLOSE_WAIT 此時我方要調用close()來使得連接正確關閉
- TIME_WAIT：我方主動調用close()斷開連接，收到對方確認後狀態變爲TIME_WAIT，TIME_WAIT狀態會一直持續2MSL(即兩倍的分 段最大生存期)，以此來確保舊的連接狀態不會對新連接產生影響。
- SYN_SENT：請求連接狀態
TCP握手爲什麼不能兩次
答：TCP握手兩次可能會出現死鎖的情況，當服務端發送迴應答報文後，若是兩次握手，那麼服務端此刻進入了ESTABLISHED的連接狀態，可以發送數據給客戶端，但是當這個應答報文中途丟失，客戶端並沒有接收到這個報文，就會發送沒收到報文給服務端，而服務端發送的數據被客戶端一直認爲是錯誤的，服務端也因爲看到客戶端發來的丟失報文以爲是發送數據錯誤而一直重複發送。
冪等和安全性
冪等：多次請求結果是一樣的
安全性：對服務器是否有改變
tcp 怎麼保證數據包有序
答：這與tcp首部報文段中的序號、確認號、確認ACK和數據報長度，tcp連接中的字節流的每一個字節都是按順序編號的，序號表示本次數據報名第一個字節的序號，確認號表示這次發送後得到的應答的第一個數據字節序號，確認ACK表示0時確認號字段無用，1時確認號有用，數據長度就是本次發送數據的長度，因此，當發送一次數據的時候，應答端根據序號和數據長度加起來計算出下一個請求發來的數據起始號，也根據請求端得到的確認號來依據發送數據。
tcp 和 udp 的異同
答：tcp是面向連接的、點對點的、可靠支付、面向字節流、提供全雙工通信的、首部開銷大（20字節）
udp是面向無連接的，盡最大努力交付的，面向報文、沒有擁塞機制，首部開銷大（8字節）
tcp 怎麼保證可靠性
答：確認丟失和確認遲到機制
確認丟失指在設定的超時重傳的時間內沒有收到確認，就認爲字節發送的分組出錯，重新發送，應答端此時接收到這個報文，重複接收就丟棄不處理，不重複就向上傳輸，但是都要發送確認報文。發送方也一樣
tcp中擁塞避免和流量控制機制
答：流量控制：利用滑動窗口來進行限制，A向B發送數據，在建立連接時，B告訴A我的接收窗口rwnd=400，告訴發送方可以發送的總數據字節的長度，從而實現流量控制，當爲0的時候就不能再發送了。
擁塞避免：有四個部分算法，慢開始、擁塞避免、快重傳和快恢復。慢開始表示當初始擁塞窗口比慢開始門限小的時候，每次發送完成，擁塞窗口就加1，從而使得擁塞窗口成指數增長，當增長到的慢開始門型後就變成擁塞避免機制了，按線性規律去增長，當增到有出現超時的情況的時候，發送方判斷爲網絡擁塞，就會調整門限值爲當前的擁塞窗口的一半，然後再重開時。有時候網絡並沒有擁塞，但是卻丟失了個別的報文表，發送方收到了重複確認的報文段，就會使用快重傳的算法，要求接收方不會發送數據的時候才攜帶確認回覆，而是一接受到數據就立馬發送確認，發送方收到連續3個重複確認，就立馬回進行快重傳，重新發送數據，也開始啓動快恢復算法，擁塞窗口降到當前的一般，並開始擁塞避免算法進行發送。
TCP四次揮手的詳細解釋
答：A發送斷開連接請求，進入終止等待狀態，B接受到請求，發送收到確認，進入關閉等待狀態，此時處於半關閉（close_wait）狀態，A沒有數據發給B，但是B可以發送給A數據，A收到B的確認後，就進入終止等待（half_close）的狀態，等B處理完所有的數據，就發送連接釋放報文給A，進入最後確認狀態，A收到後發送確認，進入時間等待狀態，B收到確認後就關閉連接，A等待2個MSL時間後沒有收到重傳就關閉連接了。
TCP揮手爲什麼不能是三次
答：TCP三次揮手，那麼在第三次的時候，即客戶端（主動揮手的一方）會進入time_wait狀態，這個時候服務端有可能還有數據要繼續發送給客戶端，而客戶端已經進入了拒絕狀態，就無法處理這些服務端還沒有來得及發送的數據。
四次揮手之後爲什麼還要等待2msl
答：一個報文的最大存活時間，確保服務端的確收到了客戶端的確認報文
滑動窗口機制的原理和理解
答：可以連續發送報文而不需要等待確認報文到達，接收方接收到會把滑動窗口往後滑動，如果發送方有一個報文缺失，接收方接受到下一個報文會重複發送這個缺失的報文，直到接受到這個報文。若接收方接受到的報文其中一個缺失了，但是下一個報文收到了，就不會重複發送。因此很大一個缺點就是浪費，後面正確的報文沒有緩存，也有選擇重傳機制，保留收到的報文到緩衝區，但是會導致亂序，因此需要排序
什麼是長鏈接
答：從HTTP/1.1開始默認使用長連接。使用長連接的HTTP協議會在響應頭加入Connection: keep-alive。當打開一個網頁客戶端和服務端建立的TCP連接不會關閉。當再次訪問服務器時還會使用這個連接。
cookie和session的區別
- session一般是服務器生成之後給服務端（通過url參數和cookie）
- cookie是實現session的一種機制，通過Http的cookie實現
- session是通過在服務器保存sessionid識別用戶，cookie存儲在客戶端
- session的保存時間是-1,關閉頁面就會消失
time_wait過多的問題
答：time_wait產生的原因是主動方發起TCP揮手的一方在最後發送確認報文後進入的狀態，這個狀態下依然保存了TCP連接的四元組，導致佔用端口不可用，而過多將會導致很多端口不可用，佔用太多資源，因此可以設置SO_REUSEADDR來讓端口可以重用，對於出於time_wait狀態的端口可以使用。
