TCP/IP(Transmission-Control-Protocol/Internet-Protocol)，中文譯名為傳輸控制協議/因特網互聯協議，又名網路通訊協議，是Internet最基本的協議、也是Internet國際互聯網路的基礎，
我上大學的時候就是一門必修課，作業后我還專門重新看了一遍，覺得比上學時理解的多了些，但是書本上東西畢竟不貼合作業，本文結合作業中常用的方面以及現實中出現過的線上問題來講解說明，
TCP/IP協議堆疊為什么是“堆疊”？
大學的時候課本上講過：開放系統互聯參考模型OSI/RM分7層，從低到高分別是物理層，資料鏈路層，網路層，傳輸層，會話層，表示層和應用層，
先從7層模型入手，是因為下面講的TCP/IP四層模型里缺少咱們平時作業中常用的RPC遠程程序呼叫協議，它作業在會話層，基于下面圖中的socket來實作，
實際上互聯網通信使用的是TCP/IP協議堆疊，這里舉例來說明為什么叫“堆疊”，
堆疊是一種先進后出的資料結構，拿一個HTTP報文來說，HTTP報文屬于應用層協議的報文，我們輸入網址，首先會呼叫到DNS協議（域名協議），HTTP報文在傳輸層用的是TCP協議，我們把TCP壓入堆疊中，再將IP層也壓入堆疊中，鏈路層的話，就用最常見的以太網，
好了，現在我們的堆疊里面從頭至尾依次是：
HTTP協議-TCP協議-IP協議-以太幀頭
然后我們先忽略最底層的物理層，假設這個封裝好的堆疊一樣的報文漂洋過海，來到了它的目的地，對端收到這個報文以后，也就是我們封裝好的這個堆疊一樣的東西以后該怎么辦呢？會不會也是先拿HTTP呢？因為這個報文是我們構造的一個堆疊，所以說它的順序肯定也是堆疊，
因此拿取的順序就是：
以太幀頭-IP協議-TCP協議-HTTP協議
在《接下來一段時間會對大家進行網路通信的魔鬼訓練-理解socket》中我講過：傳輸層操作是在內核空間完成的，就是說不是靠咱們平時的應用編碼可以直接介入的，咱們平時直接用的就是應用層協議，想通過應用層操作傳輸層怎么辦呢？這就用到了socket編程，因為HTTP協議的內容被封裝進入了socket，這里稱為套接字層，總體示意圖如下：
發現沒，最先被封裝入的HTTP報文(套接字層)是最后才被拿走的，
TCP三次握手和四次揮手
三次握手
在《懂得三境界-使用dubbo時請求超過問題》這篇文章中，我講過三次握手，這里用打比方的方式再講一遍：
我在《兩地書--K8s基礎知識》里講過司馬相如和卓文君的故事，其實在巜史記》和《漢書》里有記載說：他們的愛情是一場精心策劃的陰謀，
司馬相如從一開始就打算找個富婆，所以和當地縣令竄通，縣令經常登門拜訪司馬相如，司馬相如卻避而不見，但縣令還是天天來，很有三顧茅廬的意思，當地都在傳這個人得縣令如此垂青一定不簡單，
卓文君的爹是當地首富，聽說之后就請司馬相如去坐客，司馬相如在宴會上的目標是和卓文君建立通信聯系，他精心計算過：卓文君夫婿剛剛去世，被接回娘家，不像未出閣的姑娘那么挑剔，自己又儀表堂堂，文采不凡，應該搞得定，
但是想傍富婆的何只他一人？他精心準備了一曲《鳳求凰》，向卓文君發出第一次建立通信的請求，
第一次握手，客戶端司馬相如發出請求，服務端卓文君只有一個行程專門處理所有的連接請求，處理能力有限，所以這個才子、那個才子的建立聯系請求會先放入佇列，服務端會按照順序來處理申請，
服務端卓文君收到客戶端司馬相如的申請，會驗證收到的資訊是否有誤(實際TCP中檢驗的是通信資料是否有錯誤)，無誤則對這個客戶端的狀態變成listen狀態，并向司馬相如發出一個回執：“你的琴彈的不錯，可以建立聯系，”這就是第二次握手，
客戶端司馬相如收到服務端卓文君的回執，認為自己的目的已達到，把自己標記為established狀態，并進行第三次握手：“好的，仰慕已久，”這時候客戶端已經一廂情愿的認為自己可以自由與服務端通信了，
但是服務端卓文君那邊呢，目前還處在與客戶端司馬相如建立連接的程序中，請求在全連接佇列中排隊呢，畢竟要應付的才子多啊，客戶端司馬相如的回執還在排隊，卓文君還沒處理呢，所以這時候，客戶端司馬相如如果發了一封書信(傳輸的資料)，卓文君沒還沒跟自己丫鬟說跟客戶端司馬相如已經建立聯系了呢，所以書信根本到不了卓文君手上，這封信發送就失敗了，
等服務端卓文君處理到客戶端司馬相如的請求，真正建立連接，司馬相如的書信才真正到達卓文君手上，達到了司馬相如的第一步，
后來司馬相如讓卓文君和他私奔，他們回到司馬相如的家鄉，卓文君才發現司馬相如家一貧如洗，卓文君問娘家要錢，娘家不給，司馬相如就帶著卓文君回到了卓文君家鄉，并讓卓文君拋頭露面當廬賣酒，為的就是套路文君爸，讓他爸覺得臉上無光，主動給錢，
司馬相如計劃得逞，文君爸給了他們萬貫家財，讓他們回司馬相如老家過日子，但是錢大手大腳花，也很快花完了，司馬相如就進京找錢去了，
四次揮手
這次司馬相如果然得到了漢武帝賞識，司馬相如發達了就想休妻再娶，終于某日，客戶端司馬相如給服務端卓文君送出了一封十三字的分手信：“一二三四五六七八九十百千萬，” 無億，就是說我就你已經無意啦，這就是第一次揮手，實際上第一次揮手會告訴服務端如果你還有資料沒有發送完成，則不必急著關閉Socket，可以繼續發送資料，
服務端卓文君收到這個訊息，非常震驚，她還沒有準備好，于是，先回復了一個訊息讓客戶端司馬相如等一等，這就是第二次揮手，(這個時候客戶端就進入FIN_WAIT狀態，繼續等待服務端的FIN報文，)
在這時候，他們還是夫妻關系，服務端卓文君可以繼續給客戶端司馬相如發送訊息，服務端卓文君先回復了一首《怨郎詩》：
一別之后，
二地相思，
只道是三四月，
又誰知五六年，
七弦琴無心彈，
八行書無可傳，
九曲連環從中折斷，
十里長亭望眼欲穿，
百思想，
千系念，
萬般無奈把君怨，
萬語千言說不完，
百無聊賴十倚欄，
重九登高看孤雁，
八月中秋月圓人不圓，
七月半，秉燭燒香問蒼天，
六月伏天人人搖扇我心寒，
五月石榴似火紅，偏遭陣陣冷雨澆花端，
四月枇杷未黃，我欲對鏡心意亂，
急匆匆，三月桃花隨水轉；
飄零零，二月風箏線兒斷，
噫，郎呀郎，恨不得下一世，你為女來我做男，
等服務端卓文君把自己想說的話說完了，就給客戶端司馬相如回復說：“聞君有兩意，故來相決絕，”(出自《白頭吟》)意思是我準備好了，既然你變心啦，咱們就算了吧，這就是第三次揮手，
這時候，如果客戶端司馬相如是一般人，得償所愿了，就會回復一個：“祝你幸福，”這是韓劇里標準的分手時最后話術，是通知服務端徹底斷絕關系的，然后再等等確認服務端徹底沒有反饋就是分手成功了，這就是第四次揮手，(實際上客戶端收到FIN報文后，就知道可以關閉連接了，但是它還是不相信網路，怕服務端不知道要關閉，所以發送ACK后進入TIME_WAIT狀態，如果服務端沒有收到ACK則可以重傳，)
但是司馬相如是個藝人啊，藝人最怕脫粉啊，想想司馬相如掙錢靠的主要是《長門賦》這樣用來挽回感情的怨婦詩，自己這般鐵石心腸，那詩還有誰會買賬呢！還會得罪多少達官貴人，何況卓文君的這兩篇《怨郎詩》和《白頭吟》文采如此出眾！聰明如司馬相如馬上就知道如果不繼續維持這段才子佳人的佳話，那事業也沒了，所以他選擇了重新三次握手建立連接，
TCP長連接和短連接
TCP連接有三次握手和四次揮手的加持，被稱為可靠的連接，UDP這樣的資料報被稱為不可靠的連接，可靠就有代價，
長連接和短連接的本質區別如上圖，短連接每次通信都伴隨著三次握手和四次揮手，而長連接復用了這兩個程序，為了讓收益最大化成本最小化，不同的應用場景會選擇采用長連接或者短連接，
長連接和短連接各自的優缺點
-
長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間，但是一直連接對于客戶端來說比較耗電，
-
對于頻繁請求資源的客戶端來說，較適用長連接，
-
客戶端與服務端之間的連接如果一直不關閉的話，會存在一個問題：隨著客戶端連接越來越多，服務端早晚有扛不住的時候，這時候服務端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致服務端服務受損，
-
如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某些客戶端出問題后連累服務端，
-
短連接對于服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段，
-
一次TCP連接和斷開需要7個來回，如果客戶端請求頻繁，將在TCP的建立和關閉操作上浪費大量時間和帶寬，
短連接應用場景
一般網站類的web服務都是短連接，試想一個普通網站，比如查看我這篇公眾號文章，總共有6000多個字，一旦打開，內容加載完之后，很長時間不用再次傳輸資料，那占著連接是不是很浪費？
而且服務端可承載的最大連接數是有限的，不然檔案句柄不夠用啊，一個網站希望用幾十、幾百臺4核8G就可以支撐榷訓幾百萬，那最好使用短連接，
長連接應用場景
公司內的各個系統之間使用RPC，大家使用的工具不太相同，有的公司自己基于thrift協議進行開發，有的使用開源的Dubbo，但是大家都頭腦清醒的使用了長連接，
因為內部場景下，上下游是固定的，接入的客戶端數量也相對固定，長連接節省連接建立開銷，請求量上來了也可以直接進行資料傳輸相對高效，
公司內部使用的中間件也大多使用長連接，例如：MQ、k8s、Redis、mysql，提到這些不得不提相關的兩個技術，
keepalive保活機制
KeepAlive并不是TCP協議規范的一部分，但在幾乎所有的TCP/IP協議堆疊（不管是Linux還是Windows）中，都實作了KeepAlive功能，
先看看使用場景：
我沒看過這個電影，也不知道是哪個電影里的場景，只是知道，張藝謀在一個姑娘樓下不斷的叫喊：“安紅我想你” 這個鏡頭有段時間特別火，
客戶端張藝謀發送了訊息，服務端收到訊息后一看，瞧給你牛的，然后沒理客戶端，傻狗客戶端一直在等待，但是不知道是不是服務器掛掉了？
這時候TCP協議提出一個辦法，當客戶端端等待超過一定時間后自動給服務端發送一個空的報文，如果對方回復了這個報文證明連接還存活著，如果對方沒有報文回傳且進行了多次嘗試都是一樣，那么就認為連接已經丟失，客戶端就沒必要繼續保持連接了，如果沒有這種機制就會有很多空閑的連接占用著系統資源，原理如下圖：
如何設定它?
在設定之前我們先來看看KeepAlive都支持哪些設定項
-
KeepAlive默認情況下是關閉的，上層應用可以通過開關來開啟和關閉
-
tcp_keepalive_time: KeepAlive的空閑時長，或者說每次正常發送心跳的周期，默認值為7200s（2小時）
-
tcp_keepalive_intvl: KeepAlive探測包的發送間隔，默認值為75s
-
tcp_keepalive_probes: 在tcp_keepalive_time之后，沒有接收到對方確認，繼續發送保活探測包次數，默認值為9（次）
我們講講在Linux作業系統和使用Java如何設定，
在Linux內核設定
KeepAlive默認不是開啟的，如果想使用KeepAlive，需要在你的應用中設定SO_KEEPALIVE才可以生效，
查看當前的配置：
cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes在Linux中我們可以通過修改 /etc/sysctl.conf 的全域配置：
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9添加上面的配置后輸入 sysctl -p 使其生效，你可以使用 sysctl -a | grep keepalive 命令來查看當前的默認配置
如果應用中已經設定SO_KEEPALIVE，程式不用重啟，內核直接生效
使用Netty4設定
這里我們使用常用的Java網路框架Netty來設定，只需要在服務端設定即可：
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 100)
.childOption(ChannelOption.SO_KEEPALIVE, true)
.handler(new LoggingHandler(LogLevel.INFO));
// Start the server.
ChannelFuture f = b.bind(8088).sync();
// Wait until the server socket is closed.
f.channel().closeFuture().sync();
} finally {
// Shut down all event loops to terminate all threads.
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
這段代碼來自經典的echo服務器，我們在childOption中開啟了SO_KEEPALIVE，
Java程式只能做到設定SO_KEEPALIVE選項，其他配置項只能依賴于sysctl配置，系統進行讀取，
使用的場景
一般我們使用KeepAlive時會修改空閑時長，避免資源浪費，系統內核會為每一個TCP連接建立一個保護記錄，相對于應用層面效率更高，
常見的幾種使用場景：
-
檢測掛掉的連接（導致連接掛掉的原因很多，如服務停止、網路波動、宕機、應用重啟等）
-
防止因為網路不活動而斷連，如使用NAT代理或者防火墻的時候，經常會出現這種問題
-
HTTP協議的Keep-Alive意圖在于連接復用，同一個連接上串行方式傳遞請求-回應資料
-
TCP的KeepAlive機制意圖在于保活、心跳，檢測連接錯誤
KeepAlive通過定時發送探測包來探測連接的對端是否存活，但通常也會許多在業務層面處理，他們之間的特點是：
-
TCP自帶的KeepAlive使用簡單，發送的資料包相比應用層心跳檢測包更小，僅提供檢測連接功能
-
應用層心跳包不依賴于傳輸層協議，無論傳輸層協議是TCP還是UDP都可以用
-
應用層心跳包可以定制，可以應對更復雜的情況或傳輸一些額外資訊
-
KeepAlive僅代表連接保持著，而心跳包往往還代表客戶端可正常作業
像Dubbo這種通信中間件都使用到了TCP的保活機制，k8s客戶端和服務端是基于http協議的長連接，用到了http的保活復用連接，
連接池技術
上面四次揮手講了，如果服務器總是在斷開連接，tcp會總是處于time wait狀態，很多連接沒有得到真正的釋放，像資料庫操作，是非常頻繁的，咱們一般都不會像下圖這么每次都申請和關閉連接吧，
所以就希望盡可能的復用三次握手和四次揮手的程序，讓客戶端和服務端投入更多的資源在資料傳輸上，這就要用到連接池，
連接池是一種池式結構，其他的池式結構有：執行緒池、協程池、記憶體池和物件池，它們的實作都很接近，連接池中也有很多大家聽說過的場景，如：資料庫連接池、MQ的連接池、Redis的連接池，
提到MQ的連接池，之前的時候，有個同事排查我們使用的MQ并發吞吐太低，因為用的是標準的Java訊息服務JMS客戶端，跟了代碼發現里面用到了connection.close，就懷疑用的短連接，其實close方法的實作一般不是銷毀連接，還是歸還到連接池，
連接池咱們平時使用最多、面試最多的是其中控制伸縮性的引數：最小連接數、最大連接數，最小連接數主要是要限定池的大小，最大連接數主要是限定能打開的最大連接數，使用連接池進行通信的流程如下圖所示：
關于連接池更詳細的內容因為預計還要2千字以上，我會專門寫一篇文章來講，
細思極恐的Socket
在《接下來一段時間會對大家進行網路通信的魔鬼訓練-理解socket》中我專門講過socket，它功能強大但是讓人細思極恐，之前發生過一個線上問題，某個時刻發生了幾筆請求超時，排查發現列印Dubbo呼叫的來源IP時，觸發了DNS反決議，網路閃斷，連接不到DNS服務器，結果夯住10s直到超時，
熟悉Java語言的朋友可以了解一下當時線上問題的原因：
dubbo呼叫的來源IP使用的是dubbo的
RpcContext.getContext().getRemoteAddress().getHostName();
因為RpcContext.getContext()是基于上篇文章《ThreadLocal&MDC記憶體泄漏問題》中提到的ThreadLocal，就是保存在了執行緒里的一個固定值，所以也就相當于
new InetSocketAddress(固定的IP, 固定的埠).getHostName();
這個方法會進行DNS lookup！所以具體這個函式的執行時間受到網路狀況的影響，建議可以直接使用IP的地方使用getAddress()代替getHostName()，
這個問題可以這么來理解：
相當于在程式里執行了一個linux命令：nslookup 某IP
為什么說讓人細思極恐呢？想想看，使用Socket編程，只需一行代碼，有時候就是隱式的，實際上卻可能發出了一個繞地球半圈的信號，關鍵多數開發者還不知道，
總結
如大家所見，本篇算是《白話linux作業系統原理》的姊妹篇，和《網路通信之Session的歷史血脈》、《深入理解MQ生產端的底層通信程序-理解channel》、《接下來一段時間會對大家進行網路通信的魔鬼訓練-理解socket》、《網路位元組序列-大端序和小端序》、《https引起的跨域問題-COE&casestudy》、《懂得三境界-使用dubbo時請求超過問題》、《一個http請求進來都經過了什么(2021版)》、《架構師之路-https底層原理》是一個系列，
在之前的文章中說過，我盡量想辦法讓大家能把這些系列文章有興趣看下去，如果大家堅持下去，會對以后的作業有很大幫助，《白話linux作業系統原理》這篇文章發出之后，反饋特別好，我就在想是不是這里存在著可以讓大家堅持下去的點，可是，我自己都沒搞清楚這個點在哪里，
只要是用心寫了，對自己的知識能力也有自信，知道所寫的對大家知識能力是很有幫助的，那就堅持下去，相信可以幫助到大家，也為祖國的科技發展盡一份力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/412785.html
標籤：Linux