Linuxtcp源碼分析
tcp可實現文件傳輸 並發伺服器
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <dirent.h>
#include <errno.h>
#include <signal.h>
#include <fcntl.h>
❷ 暢談linux下TCP（上）
tcp 協議 是互聯網中最常用的協議 ， 開發人員基本上天天和它打交道，對它進行深入了解。 可以幫助我們排查定位bug和進行程序優化。下面我將就TCP幾個點做深入的探討
客戶端：收到 ack 後 分配連接資源。 發送數據
伺服器 : 收到 syn 後立即 分配連接資源
客戶端：收到ACK， 立即分配資源
伺服器：收到ACK， 立即分配資源
既然三次握手也不是100%可靠， 那四次，五次，六次。。。呢? 其實都一樣，不管多少次都有丟包問題。
client 只發送一個 SYN， server 分配一個tcb， 放入syn隊列中。 這時候連接叫 半連接 狀態；如果server 收不到 client 的ACK， 會不停重試 發送 ACK-SYN 給client 。重試間隔 為 2 的 N 次方 疊加（2^0 , 2^1, 2^2 ....）；直至超時才釋放syn隊列中的這個 TCB;
在半連接狀態下， 一方面會佔用隊列配額資源，另一方面佔用內存資源。我們應該讓半連接狀態存在時間盡可能的小
當client 向一個未打開的埠發起連接請求時，會收到一個RST回復包
當listen 的 backlog 和 somaxconn 都設置了得時候， 取兩者min值
Recv-Q 是accept 隊列當前個數， Send-Q 設置最大值
這種SYN洪水攻擊是一種常見攻擊方式，就是利用半連接隊列特性，占滿syn 隊列的 資源，導致 client無法連接上。
解決方案:
為什麼不像握手那樣合並成三次揮手? 因為和剛開始連接情況，連接是大家都從0開始， 關閉時有歷史包袱的。server(被動關閉方) 收到 client(主動關閉方) 的關閉請求FIN包。 這時候可能還有未發送完的數據，不能丟棄。 所以需要分開。事實可能是這樣
當然，在沒有待發數據，並且允許 Delay ACK 情況下， FIN-ACK合並還是非常常見的事情，這是三次揮手是可以的。
同上
CLOSE_WAIT 是被動關閉方才有的狀態 。
被動關閉方 [收到 FIN 包 發送 ACK 應答] 到 [發送FIN， 收到ACK ] 期間的狀態為 CLOSE_WAIT， 這個狀態仍然能發送數據。 我們叫做 半關閉 , 下面用個例子來分析:
這個是我實際生產環境碰到的一個問題，長連接會話場景，server端收到client的rpc call 請求1，處理發現請求包有問題，就強制關閉結束這次會話， 但是 因為client 發送 第二次請求之前，並沒有去調用recv，所以並不知道 這個連接被server關閉， 繼續發送 請求2 ， 此時是半連接，能夠成功發送到對端機器，但是recv結果後，遇到連接已經關閉錯誤。
如果 client 和 server 恰好同時發起關閉連接。這種情況下，兩邊都是主動連接，都會進入 TIME_WAIT狀態
1、 被動關閉方在LAST_ACK狀態(已經發送FIN)，等待主動關閉方的ACK應答，但是 ACK丟掉， 主動方並不知道，以為成功關閉。因為沒有TIME_WAIT等待時間，可以立即創建新的連接， 新的連接發送SYN到前面那個未關閉的被動方，被動方認為是收到錯誤指令，會發送RST。導致創建連接失敗。
2、 主動關閉方斷開連接，如果沒有TIME_WAIT等待時間，可以馬上建立一個新的連接，但是前一個已經斷開連接的，延遲到達的數據包。 被新建的連接接收，如果剛好seq 和 ack欄位 都正確, seq在滑動窗口范圍內(只能說機率非常小，但是還是有可能會發生)，會被當成正確數據包接收，導致數據串包。 如果不在window范圍內，則沒有影響( 發送一個確認報文（ack 欄位為期望ack的序列號，seq為當前發送序列號），狀態變保持原樣)
TIME_WAIT 問題比較比較常見，特別是CGI機器，並發量高，大量連接後段服務的tcp短連接。因此也衍生出了多種手段解決。雖然每種方法解決不是那麼完美，但是帶來的好處一般多於壞處。還是在日常工作中會使用。
1、改短TIME_WAIT 等待時間
這個是第一個想到的解決辦法，既然等待時間太長，就改成時間短，快速回收埠。但是實際情況往往不樂觀，對於並發的機器，你改多短才能保證回收速度呢，有時候幾秒鍾就幾萬個連接。太短的話，就會有前面兩種問題小概率發生。
2、禁止Socket lingering
這種情況下關閉連接，會直接拋棄緩沖區中待發送的數據，會發送一個RST給對端，相當於直接拋棄TIME_WAIT， 進入CLOSE狀態。同樣因為取消了 TIME_WAIT 狀態，會有前面兩種問題小概率發生。
3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse選項是 從 TIME_WAIT 狀態的隊列中，選取條件：1、remote 的 ip 和埠相同， 2、選取一個時間戳小於當前時間戳； 用來解決埠不足的尷尬。
現在埠可以復用了，看看如何面對前面TIME_WAIT 那兩種問題。 我們仔細回顧用一下前面兩種問題。 都是在新建連接中收到老連接的包導致的問題 ， 那麼如果我能在新連接中識別出此包為非法包，是不是就可以丟掉這些無用包，解決問題呢。
需要實現這些功能，需要擴展一下tcp 包頭。 增加 時間戳欄位。 發送者 在每次發送的時候。 在tcp包頭裡面帶上發送時候的時間戳。 當接收者接收的時候，在ACK應答中除了TCP包頭中帶自己此時發送的時間戳，並且把收到的時間戳附加在後面。也就是說ACK包中有兩個時間戳欄位。結構如下:
那我們接下來一個個分析tcp_tw_reuse是如何解決TIME_WAIT的兩個問題的
4、tcp_tw_recycle
tcp_tw_recycle 也是藉助 timestamp機制。顧名思義， tcp_tw_reuse 是復用 埠，並不會減少 TIME-WAIT 數量。你去查詢機器上TIME-WAIT 數量，還是 幾千幾萬個，這點對有強迫症的同學感覺很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT資源。會減少 機器上 TIME-WAIT 數量。
tcp_tw_recycle 工作原理是。
❸ 怎樣跟蹤調試linux TCP/IP協議棧源代碼
這個不是一兩句講清楚的，推薦做法： 1.《Linux源碼分析》或《Linux源碼情景分析》裡面有詳細描述，這兩本書網上很多下載的 2.如果想弄明白原理的話推薦看TCP／IP詳解
❹ linux源碼分析
linux的tcp-ip棧代碼的詳細分析
1.數據結構(msghdr,sk_buff,socket,sock,proto_ops,proto)
bsd套接字層,操作的對象是socket,數據存放在msghdr這樣的數據結構：
創建socket需要傳遞family,type,protocol三個參數，創建socket其實就是創建一個socket實例，然後創建一個文件描述符結構，並且互相建立一些關聯，即建立互相連接的指針，並且初始化這些對文件的寫讀操作映射到socket的read，write函數上來。
同時初始化socket的操作函數(proto_ops結構),如果傳入的type參數是STREAM類型，那麼就初始化為SOCKET->ops為inet_stream_ops，如果是DGRAM類型，則SOCKET-ops為inet_dgram_ops。對於inet_stream_ops其實是一個結構體，包含了stream類型的socket操作的一些入口函數，在這些函數里主要做的是對socket進行相關的操作，同時通過調用下面提到的sock中的相關操作完成socket到sock層的傳遞。比如在inet_stream_ops里有個inet_release的操作，這個操作除了釋放socket的類型空間操作外，還通過調用socket連接的sock的close操作，對於stream類型來說，即tcp_close來關閉sock
釋放sock。
創建socket同時還創建sock數據空間，初始化sock,初始化過程主要做的事情是初始化三個隊列，receive_queue(接收到的數據包sk_buff鏈表隊列),send_queue(需要發送數據包的sk_buff鏈表隊列),backlog_queue(主要用於tcp中三次握手成功的那些數據包,自己猜的),根據family、type參數，初始化sock的操作，比如對於family為inet類型的，type為stream類型的，sock->proto初始化為tcp_prot.其中包括stream類型的協議sock操作對應的入口函數。
在一端對socket進行write的過程中，首先會把要write的字元串緩沖區整理成msghdr的數據結構形式(參見linux內核2.4版源代碼分析大全),然後調用sock_sendmsg把msghdr的數據傳送至inet層，對於msghdr結構中數據區中的每個數據包，創建sk_buff結構，填充數據，掛至發送隊列。一層層往下層協議傳遞。一下每層協議不再對數據進行拷貝。而是對sk_buff結構進行操作。