由于TCP和UDP使用同樣的IP層所以對于IP層報文來說管你什協議都是他的運送數據了，事實上IP層檢查了是否本地的IP然后送往上層。UDP幾乎等同于原始數據，根據《TCPIP協議卷三》之描述說UDP要實現可靠連接就等于書寫了TCP，TCP是面向連接的，而UDP不是，書中用socket構建了TCP的SYN機理。所以我決定先對TCP下手。而TCP的龐大那是在之前早有心理準備的，你越是畏懼越是不敢，越是不敢越是畏懼，所以我想好了，要挑戰TCP源碼。只有源碼可以帶來更多的知識和編程思想，以及編程的實現。而TCP的擁塞控制只是個開始.....就像大海的一滴水，長遠了...也許一生都未必入門...可笑的是我明知道卻依舊執拗于此。。。。
測試環境：
電腦一小臺
路由器一小個
開發板一小只，
網線一小咕嚕。
TCP擁塞控制問題的引入：
在TCP連接建立之后，HSOT以最高的數據流向外推送數據得到的結果是發了一會斷開了，不僅要問問啥斷開？為什么會停止？這是我在試驗中遇到的。倘若沒有大數據，就不會停止，這是為什么？
問題表現：
以上問題經過wrieshark抓包后可以看到所有的數據。首先是SYN以及SYN所對應的ACK，再往后就是所謂的PUSH和UPADTA WIN 和WIN=0的報告包。還有部分重傳和丟失的包，最后是RST包。
按照這個來分析：首先3次握手后數據短時間內達到一個很高的值，此時大量的數據包存在于網絡中，路由器轉發中，memalloc()執行頻度頻繁。大量的數據包被擁入TCP中處理，可惜的是上層處理不過來哦，因為在RECV后面有個SEND，所以遲滯了。幸運的是TCP本身可以調整流量控制收發端的BUFF不至于溢出或者說是匹配處理能力，那么他是如何做到的呢？win 減到一定的數額就又回到原先的SYN值，在哪里更新的?那就得看代碼了：
if (sys_arch_mbox_fetch(conn->recvmbox, (void *)&p, conn->recv_timeout)==SYS_ARCH_TIMEOUT) {
memp_free(MEMP_NETBUF, buf);
conn->err = ERR_TIMEOUT;
return NULL;
buf->p = p;
buf->ptr = p;
buf->port = 0;
buf->addr = NULL;
/* Let the stack know that we have taken the data. */
msg.function = do_recv;
msg.msg.conn = conn;
if (buf != NULL) {
msg.msg.msg.r.len = buf->p->tot_len;
} else {
msg.msg.msg.r.len = 1;
}
TCPIP_APIMSG(&msg);
上面的代碼顯示了我們從郵箱中獲取數據后系統加載了一個
msg.function = do_recv; msg.msg.conn = conn;
這個代碼是什么呢》？繼續下一步：
{
tcp_recved(msg->conn->pcb.tcp, msg->msg.r.len);
}
哦這么個玩意，繼續向下：
pcb->rcv_wnd += len;
if (pcb->rcv_wnd > TCP_WND)
pcb->rcv_wnd = TCP_WND;
wnd_inflation = tcp_update_rcv_ann_wnd(pcb);
/* If the change in the right edge of window is significant (default
* watermark is TCP_WND/2), then send an explicit update now.
* Otherwise wait for a packet to be sent in the normal course of
* events (or more window to be available later) */
if (wnd_inflation >= TCP_WND_UPDATE_THRESHOLD)
tcp_ack_now(pcb);
到這里終于知道了，原來TCPWEINDOW在這里更新啊。不錯不錯。什么時候更新呢？那是有條件的
這就是條件。
于是解決了第一個疑惑那就WIN的UPDATA.
接下來就是WIN=0？為何？
其實上個問題已經解釋清楚了，我們只需要引深一下就好，那就是WIN只有在應用程序讀走TCP推上來的BUF后才會更新WIN，否則的話就會對WIN進行相應載荷的減操作。如果應用程序很忙，你叫他他并不響應，此時WIN就處于不斷下滑不斷減少的境地。然后WIN=0，最終用完了WIN，因為應用程序很忙嘛，他沒有時間了作別的他得處理，至于為什么忙，比如一個更改優先級的線程就緒了執行中而讀取他的線程掛起等待，這就是典型的。很多原因的。于是WIN=0了。HOST一看WIN=0，就想：我擦：竟然沒有空間了？好吧我停止吧。你沒地方讓我的人過去呆在那里？于是乎他等了一會就掛斷聊！一個RST隨之產生OK，這樣似乎很符合抓包獲取的流程。事實應該89不離十。這里面還有TCP的另一個概念，就是延時的概念，也就是PUSH和ACK并存的時候，在TCP數據發送的時候TCP并不是立即發送而是有規律的推遲發送，以利用一個包傳送更多的信息，這是另一個重要的模塊。不過這里不討論此方面的問題。
再回到最初的地方，如果按照以上所述則則應用層處理的越快UPDATA應該每次都很順利的更新。試試看
send(tcp_clint_sock, recv_data,bytes_received, 0);
去掉郵箱之后的此函數之后，再去開wireshak 抓取的包就是一個完美的情形，也就是預期的結果。tcp流一直持續，并沒有斷過了，這印證了之前的推論和實際情況之間是等價的。也就是說應用層只有盡快的處理完數據才可以流暢。這樣一個TCP流控就展現在面前：
例如我的demo WIN=4096
A:TCP建立連接的時候告訴主機我的接收窗口是4096 MSS=1024
B:主機知道了我的接收窗口是4096，報文長度1K，這樣主機就有數了，然后主機報告他自己的接收窗口
C：主機開始發送數據。每次發送都會+上窗口
D：從機開始回復數據。每次都會+上窗口
E：如果數據太快上層處理不過來則窗口必然會小于臨界值，極端是=0,那主機有數了就會縮減。直到窗口用完為0,B表示實在是太快了，處理不過來了。只能終止。
F：應用層適當的根據閥值更新窗口，以接收更多的字節流
也就是說流量控制實際上就是所謂的滑動窗口在起作用滴。
今天和某君討論HTTP的問題，由于某君是裸奔的所以它不存在郵箱的問題。這樣就有點麻煩了，得使用底層丟上來的BUF，結果他又忘記了在APP程序中是free掉內存，最終WEB刷新幾下就死翹翹聊。如果這里采用郵箱就不會出現內存泄露這樣的情況，如下:
/* copy the contents of the received buffer into
the supplied memory pointer mem */
netbuf_copy_partial(buf, (u8_t*)mem + off, copylen, sock->lastoffset);
系統會自動的吧BUF釋放掉并把數據COPY到應用層里面，這樣就實現了絕對的分層！這才是絕對的分層。否則就是偽分層的。應用層還是脫離不開底層的。這也是覆蓋OS和不覆蓋OS的區別之一吧。
但是使用OS時有代價的，要犧牲更多的內存和時間性。比無OS系統響應時間更慢，這是一定的。也是看應用而選擇的特殊考量。
如今互聯網普遍的時代，有誰會想到這事：1977年11月22日，載有一個無線傳輸器的一輛改裝廂式貨車通過衛星從舊金山向挪威發送了一個信號，然后又把這個信號傳輸回到加利福尼亞州，標志著TCP/IP協議第一次被用來在三個獨立的電腦網絡之間發送信號。
即使在今天我們打的DOTA我們玩的星際。QQ email 沒有一個不是基于TCPIP協議。
致敬 Bob Kahn&Vint Cerf&&Adam
老偉
日照
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
