先來說說協議可靠性，比如兩人接通**後先要寒暄幾句，一方面出於尊重，更主要目的是確認身份嘛，防止聊了半天，發現聊錯物件了哈。一樣的道理，兩台機器想要通訊互傳資料之前，先要建立連線，連線過程大致描述為：a傳送seq=a給b，b傳送ack=a+1，seq=b給a，a傳送ack=b+1給b，連線建立完成。連線釋放過程大致描述為：a傳送fin給b，b傳送ack給a，b傳送fin給a，a傳送ack給b，連線釋放完成。
我們大致明白了tcp建立連線的過程，那問題來了，為什麼是三次握手建立連線，不是兩次或四次。
如果是兩次，假設有這樣一種情況出現，a在一段時間沒有收到b的確認訊息後，會重發a的連線請求，這時b會重新為a申請資源，此時a收到了重發訊息的確認訊息後，a又收到第一次建立連線的確認訊息，a因為已經重建連線了，此時這個訊息會被丟掉，但b並不知道，這時a端有乙個連線資源，b端有兩個連線資源，所以二次握手會造成伺服器資源的浪費。三次握手b如果一直沒有收到a的確認訊息，b在一段時間後會釋放掉無效的資源，很明顯三次握手很好的解決了這個問題。四次握手的話，b給a的連線和確認訊息分兩次傳送是沒必要的，因為開始建立連線時，還沒有開始傳輸資料，所以b並沒有處理中的資料，所以b的連線請求和確認可以一次傳送給a。這裡順便提一下tcp釋放連線是四次揮手，不是三次，是因為b一方面要實時給a關閉確認，避免a超時未接到確認訊息會重發關閉請求，另一方面b的關閉連線請求要等到b端沒有處理中的資料，所以分四次釋放連線是合理可靠的。
再來了解下網路包大小，這裡只以乙太網為例來說明
網路上傳送乙個包的組成，先來看個公式：
以太幀大小=6位元組目的位址（dmac）+6位元組源位址（smac）+2位元組以太型別（ethertype）+4位元組校驗（fcs）+1500位元組資料（payload）
payload = 20位元組ip首部+20位元組tcp首部+1460應用資料
這兩個公式說明乙個乙太網包一次最多傳輸1460的應用資料。如果業務資料大於1460，ip協議會分片傳輸，先把結論寫下，我們應該盡量避免ip分片，首先分片和重組會導致效能損耗比較大，另外，ip層沒有提供重傳機制，屬於不可靠協議，也就是說如果某個分片傳輸失敗，ip層是不提供單獨傳輸單個分片的功能，只能由上層協議，如tcp將整個應用包重傳，這樣會導致極大的資源浪費；第三會導致一些安全攻擊問題，如果給接收端一直傳輸分片資訊，但不傳最後一分片，這樣接收端因沒有接收到最後一片，導致記憶體一直占用，影響正常的包傳輸；最後ip分片只有第一片攜帶了上層協議資訊，這也會給中間路由器、防火牆帶來一些安全隱患。
所以結論很明顯，我們應該盡量避免ip分片的產生，首先我們可以通過網路偵探功能獲取到整個網路鏈路的最小mtu，另外，可以強制設定ip首部不分片標識，這樣如果在網路鏈路中出現了更小的mtu，一般路由器和交換機會丟棄掉該包，然後傳送乙個攜帶mtu的icmp訊息，讓傳送端重新設定mtu並重傳。
tcp這個機制很像日常生活中工人搬磚，有的工人力氣大，一次可以搬10塊，有的工人力氣小，一次可以搬5塊，同乙個工人，剛吃飽有力氣時一次可以搬10塊，但快下班時可能一次只能搬7塊。tcp視窗機制和搬磚例子很像，視窗大小和伺服器和網路處理能力息息相關，tcp可以實時根據伺服器和網路處理能力動態調整視窗大小；tcp還提供了快速重傳機制，傳送端連續收到3次以上重複ack確認，就意識到丟包了，會馬上重傳確認段後的資料，不會等到超時再傳。
這裡涉及到幾個概念
cwnd ：擁塞視窗，採用慢啟動和試探性機制，起初每次傳輸包cwnd 會以指數方式增長，當超過乙個門閥值，會更改為線性方式增長，直到網路出現丟包，cwnd 會恢復到上乙個值；
rwnd：接收視窗，是乙個端對端的接收視窗，用於流量控制，視窗值大小代表傳送出去的但還沒收到ack確認的最大資料報文段，就是說如果視窗值為1mss，傳送端只有等每個包確認完後再傳送後面的資料，這就是停止等待協議，顯然，視窗值越大，並行傳送的資料量越大，但網路出現阻塞的情況越大；有乙個簡單辦法估算接收端rwnd值，通過rtt時間內 傳了幾個mss，一般視窗值就是多少。
net.ipv4.tcp_rmem ： tcp socket讀緩衝區，一定情況下大小決定rwnd的大小
net.ipv4.tcp_wmem ： tcp socket寫緩衝區，一定情況下大小決定rwnd的大小
net.core.rmem_max ：socket讀緩衝區
net.core.wmem_max ：socket寫緩衝區
既然談到socket，那就再談談socket的read和write函式，read函式負責把資料從socket緩衝區讀取到應用緩衝中，如果資料沒有就緒（資料已經準備好，只要有cpu資源就可以執行），執行緒會一直阻塞到資料讀取完，如果把socket設定為非阻塞，當read被呼叫，如果資料沒有就緒，函式會立即返回
說完tcp，咱來說說https，先來說說，為啥要有https，我們知道http在網路上是明文傳輸，像wireshark、finddler這樣的網路分析工具，很容易獲取到通訊內容，作為乙個碼農，酒店賬戶和訂單資料怎能公布於眾，於是我們很容易想到，既然是明文，那加密就行了，對了，https增加了tls傳輸層來對資料提供加密功能，問題是怎麼加密呢，有人說了，a端用秘鑰加密，b端用秘鑰解密，秘鑰只有a和b兩端知道，這樣不就安全了嗎，沒錯，問題又來了，a和b兩端怎麼協商秘鑰呢，事先配置好可以嗎，對於客戶端應用，勉強可以，但服務端要維護大量秘鑰，而且一旦秘鑰洩露，會導致嚴重後果，所以不可取；對於瀏覽器來說，事先配置好不可取；如果在每次建立完tcp連線後，協商出來個對稱秘鑰，問題是對稱秘鑰無法傳送給服務端，於是只能使用非對稱秘鑰，所謂非對稱秘鑰意思是，通訊兩端分別維護一套公私鑰，公鑰加密私鑰解密，網路只負責傳輸公鑰，這樣如果a端想傳資料給b，b端生成一套公私鑰並把公鑰傳輸給a，a的資料使用b的公鑰安全傳輸給b，資料即使被網路劫持，第三方因缺少私鑰無法解密資料，保證了資料的安全性，但是這裡面還是存在兩個問題。
1、a發起獲取b端公鑰的過程中，c劫持了a的連線，c生成一套公私鑰，把c的公鑰傳回給a，此時a以為拿到的是b的公鑰，實際是c的公鑰，誤用c的公鑰加密資料傳給b，這個傳送資料的連線被c劫持後，c就可以用自己生成的私鑰解密出a的資料，同時，c還可以偽造a的資訊和b通訊，這樣一看，a和b兩端都沒異常，但是資料已經洩露了。
2、使用非對稱加解密演算法效率遠遠低於對稱加解密，所以一直使用非對稱加密傳輸網路資料，不僅給通訊兩端cpu造成極大的計算量，同時也會極大增加網路負擔
所以綜上所述，對稱加密效率是相對比較高，非對稱加密安全係數比較高，怎麼辦呢，https使用非對稱加密演算法交換對稱加密秘鑰，使用對稱加密演算法傳輸實際業務資料，這樣https綜合使用了兩種加密演算法的優點，在提高網路安全性的基礎上，又同時解決了效率問題
多多指正！
網路程式設計雜談之TCP協議
tcp協議屬於網路分層中的傳輸層，傳輸層作用的就是建立埠與埠的通訊，而其下一層網路層的主要作用是建立 主機到主機 的通訊，所以在我們日常進行網路程式設計時只要確定主機和埠，就能實現程式之間的資料交流，在unix系統中就把主機 埠，叫做 套接字 socket 所以一般網路程式設計都是基於對於socke...
網路協議之TCP
為了實現計算機的通訊，我們為計算機定義了一系列的通訊規則，這些規則就是協議.資料格式封裝 傳輸 將複雜的流程分解為幾個功能相對單一的子程序。osi是乙個理想的模型，因此一般網路系統只涉及其中的幾層，很少有系統能夠具有所有的7層，並完全遵循它的規定。在7層模型中，每一層都提供乙個特殊的網路功能。從網路...
網路協議之TCP
為了實現計算機的通訊，我們為計算機定義了一系列的通訊規則，這些規則就是協議.資料格式封裝 傳輸 將複雜的流程分解為幾個功能相對單一的子程序。osi是乙個理想的模型，因此一般網路系統只涉及其中的幾層，很少有系統能夠具有所有的7層，並完全遵循它的規定。在7層模型中，每一層都提供乙個特殊的網路功能。從網路...