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