選擇重傳與分片的概念
選擇重傳不是指分片中的某個部分丟了,選擇某個分片
選擇重傳的粒度不是分片而是滑動窗口中的單元
TCP協議中的seq表示的是字節數還是包序號？
seq其實就是連接的字節數
TCP中發送數據後,基本就是已經異步過程了,應用程序沒有辦法掌控
數據僅僅是拷貝到了發送隊列中,之後的數據發送就是交給ip層了,需要做路由選擇
數據發送tcp_sendmsg中間還是需要判斷滑動窗口、擁塞窗口、nagle判斷
後續的數據發送只能靠Peer的回包的反饋來驅動滑動窗口將隊列中的數據吐出去
應用層還有一種可能通過SO_PRIORITY來優先級發送
TCP傳輸特性
時序性、通道利用率、可靠性
TCP與IP層的矛盾
從Tcp的收發包的過程和滑動窗口協議來看,Tcp依賴的是很遠地方的Peer給的信息來調整隊列中的數據發送
Tcp實際上使用兩個端點的信息來評估網絡的擁塞程度,理論上不可能準確
但是IP層卻能知道整個鏈路的擁塞程度,這種學習的信息不能夠分享給tcp的兩端
IP層的網絡很多節點是公共資源,只有處在兩端的設施是個人或者企業私有的
Tcp Recv flags 特性
MSG_TRUNK 表示不要管len這個用戶態內存有多大，只管拷貝數據
MSG_WAITALL 讀取到len長度的消息才能返回
MSG_PEEK 主要用於多進程讀取同一套接字的情形
SO_RCVLOWAT receive隊列爲空了，此時會先來檢查SO_RCVLOWAT這個閥值。
如果已經拷貝的字節數到現在還小於它，那麼可能導致進程會休眠，等待拷貝更多的數據。
SO_RCVTIMEO recv方法傳入的len參數，是表示必須超時（SO_RCVTIMEO）或者接收到len長度的消息,就會返回
阻塞方式的最長等待時間爲SO_RCVTIMEO指定的時間
TCP接受數據擁有多個隊列
receive queue 已經排好序的數據的隊列
prequeue 在進程睡眠等待的時候,新的數據包到達後,數據放到prequeue中
backlog 進程正在拷貝數據時，網卡收到的報文會進這個隊列。此時若backlog隊列有數據，就順帶處理下。
out_of_order 亂序達到的數據包的隊列,網卡收包的時候順便檢查out_of_order,將buffer從中移除,tcp_ofo_queue
SYN-COOKIE
避免內存被分配光
難道是收到的包時分配的skb_buffer導致的內存被用光嗎
網卡驅動中的內存分配應該是一開始分配一定數量的的skb_buffer,然後當數據包在中斷下半部的時候,從queue中取走放到協議棧的recv queue的時候,
這個skb_buffer的數量可能需要一定的補充
這個內存被用光是指TCB的控制塊的內存用完
當開放了一個TCP端口後，該端口就處於Listening狀態，不停地監視發到該端口的Syn報文，一旦接收到Client發來的Syn報文，
就需要爲該請求分配一個TCB，通常一個TCB至少需要280個字節，在某些操作系統中TCB甚至需要1300個字節，並返回一個SYN ACK命令，
立即轉爲SYN-RECEIVED即半開連接狀態，而某些操作系統在SOCK的實現上最多可開啓512個半開連接
對於SYN攻擊，Syn cookie爲了判斷後續對方發來的ACK報文中的SequenceNumber的正確性
完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的算法生成SequenceNumber，
這種算法考慮到了對方的IP、端口、己方IP、端口的固定信息，以及對方無法知道而己方比較固定的一些信息，
如MSS、時間等，在收到對方的ACK報文後，重新計算一遍，
看其是否與對方迴應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源
使用SIMD指令集來提高算法的運行效率
類似http中的ssl加速
SACK
SACK是TCP選項，它使得接收方能告訴發送方哪些報文段丟失，哪些報文段重傳了，哪些報文段已經提前收到等信息。
根據這些信息TCP就可以只重傳哪些真正丟失的報文段。
需要注意的是隻有收到失序的分組時纔會可能會發送SACK，TCP的ACK還是建立在累積確認的基礎上的。
也就是說如果收到的報文段與期望收到的報文段的序號相同就會發送累積的ACK，SACK只是針對失序到達的報文段的。
SACK包括了兩個TCP選項，一個選項用於標識是否支持SACK，是在TCP連接建立時時發送；另一種選項則包含了具體的SACK信息
擁塞控制算法
這是一個信號反饋的算法
捕獲突發,一旦超過了一次最大發送包(Burst),擁塞窗口就會減少
捕獲反饋(ack),擁塞窗口增加,增加的是1或者2*N個MSS
窗口大於ssthresh就進入擁塞避免
小於ssthresh就進入慢啓動
發生丟包後,sshthresh=窗口/2
ssthresh的物理意義就是帶寬
流量整形與Burst
突發導致的數據發送端的流量曲線有毛刺
RTT與RTO
RTO的初始值是3*RTT
RTO是每個鏈接維護一個,並不是每個包維護一個
RTO最小200ms,最大時間120s
in flight與Qdisc
已經亂序,但是未丟失的字節數,在路上的數據包
處在飛行狀態,還未落地
當前已經發送的-已經被確認的
tcp協議棧 in-flight = tcpdump in-flight(網卡) + Qdisc
數據包從ip層投入到了Qdisc後,怎麼觸發數據到網卡的DMA ring中
ICMP在tcp中的存在性
在connect服務器時,如果收到了icmp的不可達的數據包
則返回EUNREACH錯誤碼
發送窗口、通告窗口、擁塞窗口(CongestionWND)
發送窗口=min(aknowledge window,cwnd)
收發一致性, 收到多少個ACK包,就發送多少數據出去
擁塞窗口就是包的個數，不是字節數
當前的cwnd等於在網路中的in_flight+當前可以發送的數據
tosend等於當前被ACK的數量,表示將要發送的數據包
如果cwnd等於in flight的話，就表示不能再發送了
MSS協商與MTU
三次握手過程中就會攜帶MSS
TSO、GSO、UFO、GRO
TSO (TcpSegmentation offload)
GSO (genericsegmentation offload)
UFO (UDPfragmentation offload)
GRO(genericreceive offload)
主要是利用網卡的分片和合並分片的功能(scatter,gather),降低協議棧負擔
這些分包與合併包在網卡的驅動程序中會有體現
Delay Ack
接收端,可以一次發送對多個包的確認
不是每一次都只發一個,相當於打包多個ack發送
另外就是Ack與數據一起發送
多少路徑會發送RST
1、 目的端上並沒有監聽端口,取收到了SYN
2、 收到根本不存在的連接上的數據包
3、 關閉連接(最大連接限制,但3次握手正常)
4、linger選項會改變close的行爲,從FIN改變爲RST
數據包接收的Fast Path與Slow Path
下面的場景採用慢速路徑來處理接收包
A zero window was announced from us - zero window probing is only handled properly in the slow path.Out of order segments arrived.
Urgent data is expected.
There is no buffer space left
Unexpected TCP flags/window values/header lengths are received (detected by checking the TCP header against pred_flags)
Data is sent in both directions. Fast path only supports pure senders or pure receivers (this means either the sequence number or the ack value must stay constant)
Unexpected TCP option.
Push選項的含義
在接收方收到Push的標記時,表示將當次收到的數據與緩存中已有的數據一起提交給進程,表示完整性
Cork選項的含義
避免發送大量的小包