手冊-tcpip詳解卷2實現(xiàn)

第29 TCP的輸入(續(xù)本章從前一章結束的地方開始，繼續(xù)介紹TCP輸入處理?；叵胍幌聢D28-37中最后的測試本章處理ACK標志，更新窗口信息，處理URG標志及報文段中攜帶的所有數據，最后處在本章中，首先ACK的處理，圖29-1給出了ACK處理的框架。SYN_RCVD狀態(tài)需要特殊處理，緊跟著是其他狀態(tài)的通用處理代碼(前一章已過在LISTEN和SYN_SENT狀態(tài)下收到ACK時的處理邏輯)TCPS_FIN_AIT_1、TCPS_CLOSING和TCPS_LAST_ACKACK會導致狀態(tài)的轉移。此外，在TIME_AIT狀態(tài)下收到ACK還會導致2MSL定時器的重啟。圖29-1ACK圖29-1(續(xù)圖29-2給出了如何處理SYN_RCVD狀態(tài)下收到的ACK報文段。如前一章中提到過的，這也將完成打開(一般情況)，或者是同時打開及自連接(特殊情況)的連接建立過程。驗證收到的801-806Na(將snd_una設定為連接的ISS，SYN報文段的序號)，且小于等于snd_max。如果條件滿足，則插口進入連接狀態(tài)ESABLISHED。在收到三次握手的最后一個報文段后，調用soisconnected喚醒打開的應用進程一般為服務器)。如果服務器在調用accept上阻塞，則該調用現(xiàn)在返回。如果服務器調用807-812如果TCP曾發(fā)送窗口大小選項，并且收到了對方的窗口大小選項，則在TCP控制塊中保存發(fā)送縮放因子和接收縮放因子。另外，TCP控制塊中的snd_scale和rcv_scale的默認值為0無縮放)。813現(xiàn)在可以向應用進程提交連接重組隊列中的數據，調用tcp_reass，第二個參數為空。重組隊列中的數據可能是SYN報文段中攜帶的，它同時將連接狀態(tài)變遷為SYN_RCVD。81 snd_wl1等于收到的序號減1，從圖29-15可知，這樣將導致更新3圖29-3給出了ACK處理的下一部分代碼，處理重復ACK，并決定是否起用TCP的快速重傳和快速恢復算法[Jacobson1990c][Floyd1994]?？焖僦貍魉惴ㄓ糜谶B續(xù)出現(xiàn)幾次(一般為3次)重復ACK時，TCP認為某個報文段已丟失并且從中推斷出丟失報文段的起始序號，丟失報文段被重傳。RFC1122中的1節(jié)提到了這一算法，建議TCP收到亂序報文段后，立即發(fā)送ACK?？吹剑趫D27-15中，Net/3正是這樣做的。這個算法最早出現(xiàn)在4.3BSDTahoe版及后續(xù)的Net/1實現(xiàn)中，(即丟失報文段已重傳)，應執(zhí)行擁塞避免算法，而非慢起動。這樣，如果擁塞不嚴重，還能保證較大的吞吐量，尤其窗口較大時。這個算法最早出現(xiàn)在4.3BSDReno版和后續(xù)的Net/2實現(xiàn)中。在圖24-17節(jié)中，提到有效的ACK必須滿足下面的不等式：snd_una確認字段第一步只與snd_una29-5中再進行不等式第二部分的比較。分開比較的原因是為了能對收到的ACK完成下列5項測試：如果確認字段小于等于snd_una；并接收報文段長度為0；并窗口通告大小未變連接上部分發(fā)送數據未被確認(重傳定時器非零)；并接收報文段的確認字段是TCP收到的最大的確認序號(確認字段等于snd_una)之后可確認報文段是完全重復的ACK(測試項1、2和3在圖29-3中，測試4和5在圖29-4的起始TCP統(tǒng)計連續(xù)收到的重復ACK的個數，保存在變量t_dupacks中，次數超過門限(tcprexmtthresh，3)時，丟失報文段被重傳。這也就是卷1第21.7節(jié)中介紹的快速重傳算法。它與圖2７-15中的代碼互相配合：當TCP收到亂序報文段時，立即生成一個重復的ACK，告訴對端報文段有可能丟失和等待接收的下一個序號值?？焖僦貍魉惴ㄊ菫榱俗孴CP立即重傳看上去已經丟失的報文段，而不是地等待重傳定時器超時。卷1第21.7節(jié)舉例詳細說明了圖29-3tcp_input函數：判定完全重復的ACK了一個亂序報文段，從而開始發(fā)送重復的ACK。快速恢復算法要求連續(xù)收到幾個重復ACK后，TCP應該執(zhí)行擁塞避免算法(如降低速度)，而不一定必需等待連接兩端間的管道清空(慢起動)?！半x開了網絡”指數據分組已被對端接收，并加入到連接的重組隊列中，不再滯留在傳輸途如果前述5項測試條件只有前3項為真，說明ACK是重復報文段，統(tǒng)計值ck加1，而連續(xù)重復ACK計數器(t_dupacks)復位為0。如果僅有第一項測試條件為真，則計數器t_dupacks復位為0。圖29-4給出了快速重傳算法其余的代碼，當所有5個測試條件全部滿足時，根據已連續(xù)收t_dupacks等于3(tcprexmtthresh)，則執(zhí)行擁塞避免算法，并重傳丟失報文t_dupacks大于3，則增大擁塞窗口，執(zhí)行正常的TCP輸出t_dupacks小于3，不做圖29-4tcp_input函數：處理重復的連續(xù)收到的重復ACK次數己達到門限值861-868t_dupacks等于3(tcprexmtthresh)時，在變量onxt中保存snd_nxt值，令慢起動門限(ssthresh)等于當前擁塞窗口大小的一半，最小值為兩個最大報文段長度。這與圖25-27中重傳定時器超時處理中的慢起動門限設定操作類似，但看到，超時處理中把擁塞窗口設定為一個最大報文段長度，快速重傳算法并不這樣做。869870關閉重傳定時器。為防止TCPt_rtt871873從連續(xù)收到的重復ACK報文段中可判斷出丟失報文段的起始序號(重復ACK的確認發(fā)送丟失報文段(參見卷1的圖21-7中的63號報文段)。874-875擁塞窗口等于慢起動門限加上對端高速緩存的報文段數?！案咚倬彺妗敝笇Χ艘咽盏降膩y序報文段數，且為這些報文段發(fā)送了重復的ACK。除非對端收到了丟失的報文段(剛剛發(fā)送)，這些緩存報文段中的數據不會被提交給應用進程。卷1的圖21-10和圖21-11給出了快速設定876-878比較下一發(fā)送序號(snd_nxt)的先前值(onxt)和當前值，將兩者中最大的一個重新賦還給snd_nxt，因為重傳報文段時，tcp_output會改變snd_nxt。一般情況下，snd_nxt將等于原來保存的值，意味著只有丟失報文段被重傳，下一次調用tcp_output時，連續(xù)收到的重復ACK數超過門限879-883 因為t_dupacks等于3時，已重傳了丟失的報文段，再次收到重復ACK說明又有另一個報文段離開了網絡。擁塞窗口大小加1，調用tcp_output發(fā)送序列中的下一報文段，884885ACK，且長度非零或者通告窗口大小發(fā)生變化，則執(zhí)行這些語句。此時，前面提到的5個測試條件中只有第一個為真，連續(xù)收到的重復ACK數被略過ACK處理的其余部886 break語句在下列3(1)前述5(2)只有前3個條件為真；(3)重復ACK次數小于門限值3。任何一種情況下，盡管收到的是重復ACK，將執(zhí)行break語句，控制跳到圖29-2中switch語句的結尾處，在標注step6處繼續(xù)8而本地報文段1~8已發(fā)送。報文段1丟失，其余報文段均正常到達且被確認。收到對報文段2、3和4的確認后，重傳丟失的報文段(15~8TCP夠發(fā)送報文段9，以高的吞率但窗口小于8，送報文段9及其后續(xù)報文段。因此，每當再次收到一個重復的ACK，就暫時把擁塞窗口加1，因為收到重復的ACK告訴TCP1的確認后，下面將介紹的代碼會減少擁塞窗口大小，令其等于慢起動門限。卷1的圖21-10舉例說明了這一過程，重復ACK到達時，增加擁塞窗口大小，之后收到新的ACK時，再相應地減少擁塞窗口。圖29-5中的代碼繼續(xù)處理ACK888-895如果連續(xù)收到的重復ACK數超過了門限值3，說明這是在收到了4個或4個以上的重復ACK后，收到的第一個非重復的ACK?？焖僦貍魉惴ńY束。因為從收到的第4個重復ACK開始，每收到一個重復ACK就會導致?lián)砣翱诩?，如果它已超過了慢起動門限，令其檢查ACK的有效896899前面介紹過，有效的ACKsnd_una確認字段<=如果確認字段大于snd_max，可對端正在確認了TCP尚未發(fā)送的數據?？赡艿脑蚴?，對于高速連接，某個的ACK再次出現(xiàn)時，序號已回繞，從圖24-5可知，這是極為罕見的900902經過前面的測試，已知這是一個有效的ACK。acked等于確認的字節(jié)數。903-915如果(1)時間戳選項存在；或者(2)TCP對某個報文段計時，且收到的確認字段大于該報文段的起始序號，則調用tcp_xmit_timer更新RTT測算值。注意，使用時間戳時，tcp_xmit_timer的第二個參數等于當前時間(tcp_now)減去收到的時間戳回顯(ts_ecr)由于延遲ACK的存在，面的測試不等式中應采用大于號。例如，假定TCP發(fā)送了一1~10241025~2048。如果收到的確認字段等于2049，因為2049大于1(計文段的起始序號)，TCP將更新TT測算值。916-924如果收到報文段的確認字段(ti_ack)等于TCP的最大發(fā)送序號(snd_max)，說明所有已發(fā)送數據都已被確認。關閉重傳定時器，并置位needoutput標志，從而在函數結束時強迫調用tcp_output。這是因為在此之前，有可能因為發(fā)送窗口已滿，TCP了等待發(fā)送的數據，而現(xiàn)在收到了新的ACK，確認了全部已發(fā)送數據，發(fā)送窗口能夠向右移動(圖29-8中的snd_una被更新)，允許發(fā)送的數據。925-926 注意，時間戳的運用取消了Karn算法的部分規(guī)定(卷1的21.3節(jié))：如果重傳定時器超時，則報文段被重傳，收到對重傳報文段的確認時，不應據此更新TT測算值(重傳確認的二義性問題)。在圖25-26中，看到當發(fā)生重傳時，遵從Karn，t_rtt被設為0。如果時間戳不存在，且收到的是對重傳報文段的確認，則圖29-中的代碼不會更新TT測算值，因為此時t_rtt等于0。但如果時間戳存在，則不查看t_rtt值，允許利用收到的時間戳回顯字段更新TT測算值。根據RFC1323，時間戳的運用不存在二義性，因為ts_ecr的值自被確認的報文段。Karn算法中關于重傳報文段時應采用指數退避的策略依舊有效。圖29-7給出了ACK處理的下一部分代碼，更新?lián)砣皥D29-7tcp_input函數：響應收到的ACK

圖29-7續(xù)927-94 慢起動和擁塞避免的一條原則是收到ACK到一個ACK(慢起動)，擁塞窗口將加1。但如果當前擁塞窗口大于慢起動門限，增加值等于incr*incr/t_maxseg*t_maxseg/即1除以擁塞窗口，因為snd_cwnd的單位為字節(jié)，而非報文段。表達式的常量部分等于最大報文段長度的1/8。此外，擁塞窗口的上限等于連接發(fā)送窗口的最大值。算法的舉例參見卷的21.8添加一個常量最大報文段長度的1/8)是錯誤的[Floyd1994]BSD源碼中，從4.3BSD到4.4BSD和Net/3圖29-8給出了tcp_input下一部分的代碼，從發(fā)送緩存中刪除已確認的數94394 如果確認字節(jié)數超過發(fā)送緩存中的字節(jié)數，則從snd_wnd節(jié)數，并且可知本地發(fā)送的FIN已被確認。調用sbdrop從發(fā)送緩存中刪除所有字節(jié)。能夠以這種方式檢查對FIN報文段的確認，是因為FIN在序號空間中只占一個字節(jié)。947-951如果確認字節(jié)數小于或等于發(fā)送緩存中的字節(jié)數，ourfinisacked等于0，并從951-956調用sowwakeup喚醒所有等待發(fā)送緩存的應用進程，更新snd_una保存最老的未被確認的序號。如果snd_una的新值超過了snd_nxt，則更新后者，因為這說明中間的數據也被確認。圖29-9舉例說明了為什么snd_nxt保存的序號有可能小于snd_una。假定傳輸了兩個報文段，第一個攜帶字節(jié)1~512，而第二個攜帶字節(jié)513~1024。一一個報一個報圖29-9確認返回前，重傳定時器超時。圖25-26中的代碼將snd_nxt設定為snd_una，進入慢起動狀態(tài)，調用tcp_output重傳攜帶1~512字節(jié)的報文段。tcp_output將snd_nxt增加為513，如圖29-10所示。 報文段重 圖29-10重傳定時器超時后的連接(接圖29-此時，確認字段等于1025的ACK到達(或者是最初發(fā)送的兩個報文段或者是ACK在網絡中被延遲)。這個ACK是有效的，因為它小于等于snd_max，但它也將小于更新后的snd_una值。一般性的ACK處理現(xiàn)在已結束，圖29-11中的switch語句接著處理了4種特殊情況圖29-11tcp_input函數：在FIN_WAIT_1狀態(tài)時收到了在FIN_WAIT_1狀態(tài)時收到了

圖29-11(續(xù)958-971TCP已發(fā)送了FIN，但還有可能收到對在FIN之前發(fā)送的報文段的確認。因此，只有在收到FIN的確認后，連接才會轉移到FIN_AIT_2圖29-8ourfinisacked標志已置位，這取決于確認的字節(jié)數是否超過發(fā)送緩存中的數據量。設定FIN_WAIT_2定時972-975在256節(jié)中介紹了Net3如何設定FINAI_定時器，以防止在INWAI_2狀態(tài)無限等待。只有當應用進程完全關閉了連接(如號量終止時與類似的內核調用)，而不是半關閉時(如已發(fā)送了FIN上接收數據圖29-12給出了在CLOSING狀態(tài)收到ACK時的處理代碼圖29-12tcp_input函數：在CLOSING狀態(tài)收到在CLOSING狀態(tài)收到979-992如果收到的ACK是對FIN的確認()MEAIT狀態(tài)。所有等待的定時器都被清除(如等待的重傳定時器)，IMEAIT定時器被啟動，時限等于兩倍的MS。圖29-13給出了在LAST_ACK狀態(tài)收到ACK的處理代碼圖29-13tcp_input函數：在LAST_ACK狀態(tài)收到在LAST_ACK狀態(tài)收到993-1004如果FIN已確認，連接將轉移到CLOSED狀態(tài)。tcp_close將負責這一狀態(tài)變遷，并同時InternetPCB和TCP控制塊。圖29-14給出了在TIME_WAIT狀態(tài)收到ACK的處理代在TIME_WAIT狀態(tài)收到1005-1014此時，連接兩端都已發(fā)送過FIN，且兩個FIN都已被確認。但如果TCP對遠端FIN的確認丟失，對端將重傳FIN帶有ACK。TCP丟棄報文段并重傳ACK。此外，TCP控制塊中還有兩個窗口變量未曾提及：snd_wl1和snd_wl2nd_wl1記錄最后接收報文段的序號，用于更新發(fā)送窗口(snd_wnd)snd_wl2記錄最后接收報文段的確認序號，用于更新發(fā)送窗到目前為止，只在連接建立時(主動打開、打開或同時打開)遇到過這兩個變量，snd_wl1被設定為ti_seq減1。當時說是為了保證窗口更新，下面的代碼將證明這一如果下列3個條件中的任一個被滿足，則應根據接收報文段中的通告窗口值(tiwin)更新發(fā)報文段攜帶了新數據。因為snd_wl1保存了用于更新窗口的最后接收報文段的起號，如果snd_wl1<ti_seq，說明此條件為報文段未攜帶新數據(snd_wl1等于ti_seq)，但報文段確認了新數據。因為snd_wl2<ti_ack報文段未攜帶新數據，也未確認新數據，但通告窗口大于當前發(fā)送這些測試條件的目的是為了防止舊的報文段影響發(fā)送窗口，因為發(fā)送窗口并非序號序列，而是從snd_una算起的偏移量。10151023if語句檢查報文段的ACK標志是否置位，且前述3個條件中是否有一個被滿足。前面介紹過，在LISTEN狀態(tài)或SYN_SENT狀態(tài)收到SYN后，控制將跳轉到step6，而在注釋中的TAC指“終端接入控制器(terminalaccesscontroller)”，是ARPANET上 1024-1027如果收到一個純窗口更文段(長度為0，ACK未確認新數據，但通告窗口增1028-1033更新發(fā)送窗口，保存新的snd_wl1和snd_wl2值。此外，如果新的通告窗口是TCP從對端收到的所有窗口通告中的最大值，則新值被保存在max_sndwnd中。這是為了猜測對端接收緩存的大小，在圖26-8中用到了此變量。更新snd_wnd后，發(fā)送窗口可用空間增加，從而能夠發(fā)送新的報文段，因此，needoutput標志置位。TCP輸入處理的下一部分是URG標志置位時的報文段。如圖29-16所示是否需要處理URG1035-1039只有滿足下列條件的報文段才會被處理：URG標志置位，緊急數據偏移量(ti_urp)非零，連接還未收到FIN。只有當連接的狀態(tài)等于TIME_WAIT時，宏TCPS_HAVERCVDFIN才會為真，因此，連接處于任何其他狀態(tài)時，URG都會被處理。在后面的注釋中提到，連接處于CLOSE_WAIT、CLOSING、LAST_ACK和TIME_AIT等幾個狀態(tài)時，URG標志會被忽略，這種說法是錯誤的。1040-1050如果緊急數據偏移量加上接收緩存中已有的數據超過了插口緩存可容納的數據量，則忽略緊急標志。緊急數據偏移量被清零，URG標志被清除，剩余的緊急方式處理邏輯圖29-17給出了tcp_input下一部分的代碼，處理緊急圖29-17(續(xù)1051-1065明已收到了一個新的緊急指針。例如，圖26-30中的攜帶3字節(jié)的報文段到達接收方，如圖29-接收報緊急數據偏移一般情況下，收到的緊急指針(rcv_up)等于rcv_nxt。這個例子中，因為if語句接收報緊急數據偏移1066-1070的分界點，應計入接收緩存中已有的數據(so_rcv.sb_cc)在面的例中假定接收緩存為空， 等2：序號為

圖29- 點上。如果發(fā)送帶外數據的d系統(tǒng)調用給定長度為1，并且這個報文段到達對端時接收緩存為空，就會發(fā)生這一現(xiàn)象，同時也再次重申了Bkeley系統(tǒng)認為緊急指針應指向帶外數據后的向應用進程通告TCP的緊1071-1072調用sohasoutofbandTCPOOB_HAVEDATA和TCPOOB_HADDATA，它們用于圖30-8中的PRU_RCVOOB請求處理1074-1085 如果緊急數據偏移量小于等于接收報文段中的字節(jié)數，說明帶外數據包含在報文段中。TCP的緊急方式允許緊急數據偏移量指向尚未收到的數據。如果定義了SO_OOBINLINE常量(Net/3定義了此常量)，而且未選用對應的插口選項，則接收進程從常的數流提取帶數，并保在t_iobc變量中。完成這能的函數，是在下一節(jié)介紹的tcp_pulloutofband。注意，無論緊急指針指向的字節(jié)是否可讀，TCP都將通知接收進程發(fā)送方已進入緊急方式。1086-1093在接收處理緊急指針時，如果rcv_nxt大于接收緊急指針，則rcv_up向右移動，并等于rcv_nxt。這使接收緊急指針一直指向接收窗口的左側，確保在收到URG標如果要實現(xiàn)習題26.6中方案，也必須相應修改圖29-16和圖29-17中的接收報文段中帶有緊急方式標志帶外數據包含在接收報文段中(如，緊急指針指向接收報文段)；并未選用SO_OOBINLINE選項函數從正常的數據流(保存接收報文段的mbuf鏈中提取帶外字節(jié)，并保存在連接TCP控制塊中的t_iobc變量中。應用進程通過recv系統(tǒng)調用，置位MSG_OOB標志，這個變量圖30-8中的PRU_RCVOOB請求。圖29-19給出了函數代碼。圖29-19(續(xù)12821289考慮圖29-203，因此緊急指針等于7，帶外字節(jié)變量cnt等于2，因為m_len(等于5)大于2，執(zhí)行if語句為真部分的代12901298cp指向序號6的字節(jié)，它被放入保存帶外字節(jié)的變量t_iobc中。置位TCPOOB_HAVEDATA標志，調用bcopy將接下來的兩個字節(jié)(序號7和8)左移1字節(jié)，如圖29-接收接收報緊急數據偏移圖29- 圖29- 移走帶外數據后的結果(接圖29-注意，數字7和8指數據字節(jié)的序號，而不是其內容。mbuf的長度從5減為4但ti_len仍等于5不變，這是為了按序把報文段放入插口的接收緩存。TCP_REASS宏和tcp_reass函數(在下一節(jié)調用)會給rcv_nxt增加ti_len，本例中ti_len必須等于5，因為下一個等待接收的序號等于9。還請注意，函數沒有對第一個 mbuf中的數據分組首部長度(m_pkthdr.len)減1，這是因為負責把數據添加到插口接收緩存的sbappend不使用此長度值。跳至鏈中的下一個1299-1302如果帶外數據未保存在此mbuf中，則從cnt中減去mbuf中的字節(jié)數，處理鏈中的下一個mbuf。因為只有當緊急數據移量指向接收報文段時，才會調用此函數，所以，如果鏈已結束，不存在下一個mbuf，則執(zhí)行break語句，跳轉到標注panic處。tcp_input接著提取收到的數據(如果存在)，將其添加到插口接收緩存，或者放入插口的亂序重組隊列中。圖29-22給出了完成此項功能的代碼。10941105接收數據的長度大于0，或者FIN標志置位；并連接還未收到則調用宏TCP_REASS處理數據。如果數據次序正確(如，連接等待接收的下一序號)，置位延遲ACK標志，增加rcv_nxt，并把數據添加到插口的接收緩存中。如果數據次序錯誤，宏會調用tcp_reass函數，把數據加入到連接的重組隊列中(新到數據有可能填充隊列中的缺口，從而將已排隊的數據添加到插口的接收緩存中)。前面介紹過，宏的最后一個參數(tiflags)是可修改的。特別地，如果數據次序錯誤，tcp_reass令tiflags等于0，清除FIN標志(如果它已置位)。這也就是為什么即使報文段中沒有數據，只要FIN置位，if語句也為真。考慮下面的例子。連接建立后，發(fā)送方立即發(fā)送報文段：一個攜帶字節(jié)1~1024，另一個攜帶字節(jié)1025~2048，還有一個未帶數據的FIN。第一個報文段丟失，因此，第二個報文段到達時(字節(jié)1025~2048)ACK。當第三個帶有FIN29-220，因為FIN置位，導致調用TCP_REASS，它接著調用tcp_reass。因為ti_seq(2049，F(xiàn)IN的序號)不等于rcv_nxt(1)，tcp_reass返回0(圖2７-23)。在TCP_REASStiflags被設為0，從而清除了FIN標志，后續(xù)代碼(圖29-10)繼續(xù)處理FIN。1106-1111計算len，實際上是在猜測對端發(fā)送緩存的大小。考慮下面的例子。插口接收緩存大小等于8192(Net/3的默認值)TCP在SYN8192。之后收到第一個報文段，攜帶字節(jié)1~1024。圖29-23給出了在TCP_REASS增加rcv_nxt以反應收到的數據后接收空間的狀態(tài)。圖29-23大小為8192的接收窗口收到字節(jié)1~1024此時，經計算，len等于1024。對端向接收窗口發(fā)送數據后，len值將增加，但絕不會超過對端發(fā)送緩存的大小。前面介紹過，圖29-15中對變量max_sndwnd的計算，是在猜測事實上，變量len從未被使用。它是從Net/1遺留下來的，len計算后被TCP控制塊的max_rcvd變量中if(len>tp->max_rcvd)tp->max_rcvd=len;但即使在Net/1中，變量max_rcvd也未被使用1112-1115如果len等于0，且FIN標志未置位，或者連接上已收到了FIN，則丟棄保存接tcp_input的下一步，在圖29-24中給出，處理FIN標志處理收到的第一個1116-112 如果接收報文段FIN置位，并且是連接上收到的第一 FIN，則調socantrcvmore，把插口設為只讀，置位TF_ACKNOW，從而立即發(fā)送ACK()rcv_nxt加1，越過FIN占用的序號1126FIN處理的其余部分是一個大的switch語句，根據連接的狀態(tài)進行轉換。注意，連接處于CLOSE、LISTEN和SYN_SENT狀態(tài)時，不處理FIN，因為處于這3個狀態(tài)時，還未收到對端發(fā)送的SYN，無法同步接收序號，也就無法驗證FIN序號的有效性。此外，連接處于CLOSING、CLOSE_WAIT和LAST_ACK狀態(tài)時，也不處理FIN，因為在這3個狀態(tài)下收到的FIN必然是一個重復報文段。SYN_RCVD和ESTABLISHED1127-1134如果連接處于SYN_RCVD或ESTABLISHED狀態(tài)，收到FIN盡管在SYN_RCVD狀態(tài)下收到FIN是合法的，但卻極為罕見。圖24-15的狀態(tài)圖未列出這一狀態(tài)變遷。它意味著處于LISTEN狀態(tài)的插口收到一個同時帶有SYN和FIN的報文段?；蛘撸诘牟蹇谑盏搅薙YN，連接轉移到SYN_RCVD狀態(tài)，但在收到ACK之前，先收到了FIN(FIN未攜帶有效的ACK，否則，圖29-2中的代碼會使連接轉移到ESABLISHED狀態(tài))。圖29-25給出了FIN處理的下一部FIN_WAIT_11135-1141因為報文段的ACK處理已結束，如果處理FIN時，連接處于FIN_WAIT_1狀態(tài)，意味著連接兩端同時關閉連接—兩端發(fā)送的兩個FIN在網絡錯。連接進入CLOSING狀態(tài)FIN_WAIT_21142-1148 收到FIN將使連接進入TIME_AIT狀態(tài)。當在FIN_AIT_1狀態(tài)收到攜帶ACK和FIN的報文段時(典型情況)，盡管圖24-15顯示連接直接從FIN_WAIT_1轉移到TIME_AIT狀態(tài)，但在圖29-1中處理ACK時，連接實際已進入FIN_AIT_2狀態(tài)。此處的FIN處理再將連接轉到TIME_AIT狀態(tài)。因為ACK在FIN之前處理，所以連接總會經過FIN_AIT_2盡管是暫時性的。啟動TIME_WAIT定時1149-1152 關閉所有等待的TCP定時器，并啟動TIME_AIT定時器，時限等于MSL(接收報文段中包含ACK和FIN，圖29-1中的代碼會啟動FIN_AIT_2定時器)TIME_WAIT1153-1159如果在TIME_WAIT狀態(tài)時收到FIN，說明這是一個重復報文段。與圖29-14中圖29-26給出了tcp_input函數中首部失敗時，較慢的執(zhí)行路徑中最后一部分的代碼，以及標注dropafterack。SO_DEBUG插口選

1161-1162如果選用了SO_DEBUG插口選項，則調用tcp_trace向內核的環(huán)形緩存中添加記錄?；叵胍幌?，圖28-7中的代碼同時保存了原有連接狀態(tài)，IP和TCP的首部，因為函數有調用1163-1168如果needoutput標志置位(圖29-6和圖29-15)，或者需要立即發(fā)送ACK，則調1169-1179只有當RST標志未置位時，才會生成ACK(帶有RST的報文段不會被確認)，釋圖29-27結束tcp_input函數

11801188除了接收報文段也有RST此處的代碼存在與圖28-16同樣的錯誤：它查接收報文段的目的地址是否為類似地 IN_MULTICAST的目的地址參數應轉換為主機字節(jié)序11891196RST報文段的序號字段值、確認字段值和ACK標志取決于接收報文段中是否帶圖29-28總結了生成RST報文段中的這些字段接收到的報文生成的RST序號不帶接收到的確認字00接收到的序號字圖29- 生成RST報文段各字段的正常情況下，除了起始的SYN(圖24-16)，所有報文段都帶有ACK。tcp_respond的第1192-1193 如果SYN置位，則ti_len必須加1，從而生成RST的確認字段比收到的SYN報1。如果到達的SYN請求與不存在的服務器建立連接，會執(zhí)行這一段代碼。此時，由于圖28-6中的代碼找不到請求的InternetPCB，控制跳轉到dropwithreset。但為了使發(fā)送的RST能被對端接受，報文段必須確認SYN(圖28-18)。卷1的18.14節(jié)舉例說明了這種類型的RST。最后請注意，tcp_respond利用保存接收報文段的第一個mbuf構造RST，并且鏈上1197-1199如果在圖28-7中為的服務器創(chuàng)建了臨時的插口，但圖28-16中的代碼發(fā)現(xiàn)接收報文段有錯誤，它會置位dropsocket。如果出現(xiàn)了這種情況，插口在此處被。丟棄(不帶ACK或1201-1206 如果接收報文段被丟棄，且不生成ACK或RST，則調用tcp_trace。如果SO_DEBUG置位且生成了ACK，則tcp_output將向內核的環(huán)形緩存中添加一條記錄。如果SO_DEBUG置位且生成了RST，系統(tǒng)不會為RST添加新的記錄。1207-1211保存接收報文段的mbuf鏈。如果dropsocket非零，則臨時創(chuàng)建的插為了加速TCP處理而進行的優(yōu)化與UDP類似(23.12節(jié))。應利用數據計算檢驗和，并避免在處理中多次遍歷數據。[Daltonetal.1993]了這些修訂。連接數增加時，對TCPPCB的線性搜索也是一個處理瓶頸。[McKenneyandDove1992]討[Partridge1993]介紹了VanJacobson開發(fā)的一個用于研究目的的協(xié)議實現(xiàn)，極大地減少了TCPIP進行處理(RISC系統(tǒng)中約有25條指令)，之后由分用器(demultiplexer)尋找PCB(約10條指令)，最后由TCP處理(約30條指令)。這30條指令完成了首部，并計算偽首部檢驗和。如果數據報文段通過了首部，且應用進程正等待接收數據，則數據到應用進程緩存，計算TCP檢驗和并完成驗證(一次遍歷中完成數據和檢驗和計算)。如果TCP首部失敗，則執(zhí)行TCP輸入處理中較慢的路徑。下面介紹TCP首部壓縮。盡管首部壓縮不是TCP輸入處理的一部分，但需要徹底了解的工作機制后，才能很好地理解首部壓縮。RFC1144[Jacobson1994a]中詳細定義了首部壓縮，因為VanJacobson首先提出了這一算法，通常也稱為VJ首部壓縮。本節(jié)的目的不是詳細首部壓縮的源代碼(RFC1144給出了實現(xiàn)代碼，其中有很好的注釋，程序量與tcp_output差不多)，而是概括性地介紹一下算法的思想。請注意區(qū)分首部(28.4節(jié))和首部壓縮。多數的SLIP和PPP實現(xiàn)支持首部壓縮。盡管首部壓縮，在理論上，適用于任何數據鏈路，但主要是向慢速行路。首壓只處理TCP報文段—與其他的IP協(xié)議無關(如ICM、IGMP、UDP等等)。它能夠把IP/TC組合首部從正常的40字節(jié)壓縮到只有3字節(jié)，從而降低了交互性應用，如登錄或 net中TCP報文段的大小，從典型的41字節(jié)減少到只剩4字節(jié)—大大提高了慢速串行鏈路的效串行鏈路的兩端，每端都著兩個連接狀態(tài)表，一個用于數據報的發(fā)送，另一個用于256條記錄，但典型的只有1616條不同的TCP8bit的連接ID(限制記錄數最多只能為256)、某些標志和最近接收/96bit的插口對可惟一確定一條連接—源端IP地址和TCP端口、目的IP地址和TCP端口—這些信息都保存在未壓縮的首部中。圖29-29舉例說明了這些表的結構。發(fā)送連接狀態(tài)標號標 最近的/P首接收連接狀態(tài)標號標 最近的IP/T首接收連接狀態(tài)標號標 最近的IP/T首發(fā)送連接狀態(tài)標號標 最近的IP/T發(fā)送連接狀態(tài)標號標 最近的/P首接收連接狀態(tài)標號標 最近的IP/T首接收連接狀態(tài)標號標 最近的IP/T首發(fā)送連接狀態(tài)標號標 最近的IP/T首圖29- 鏈路(如SLIP鏈路)兩端的一組連接狀態(tài)在圖29-29中利用數組表示這些表，但在源代碼中，表項定義為一個結構，連接狀態(tài)表定義為這些結構組成的環(huán)形鏈表，最近一次用過的結構位于表頭。因為連接兩端都保存了最近用過的未壓縮的數據報首部，所以只需在鏈傳送當前數據報與前一數據報不同的字段及一個特殊的前導字節(jié)，指明后續(xù)的是哪一個字段)。因為某些首部字段在相鄰的數據報之間不會變化，而其他的首部字段變化也很小，這種差分處理是壓縮算法的。首部壓縮只適用于IP和TCP首部—TCP報文段的數據部分不圖29-30給出了發(fā)送方利用首部壓縮算法，在串行鏈發(fā)送IP數據報時采取的步驟待待發(fā)送的數據非TCP報文壓縮的TCPIP其 找COMPRESSED_TCP無 壓未找PRESSED_TCP壓配的96-bit插口檢查數圖29- IP型數據報，前導字節(jié)的4比特等于4。這也是IP首部中正常的IP版本號(圖8-8)，COMPRESSED_TCP型數據報，前導字節(jié)的最置為1，類似于IP版本號介于8和15之間(剩余的7bit由壓縮算法使用)，說明鏈發(fā)送的是壓縮過的首部和未壓縮的數據，接下來PRESSED_TCP型數據報，前導字節(jié)的4比特等于7，說明鏈發(fā)送的是正常的、未壓縮的數據報，但IP的協(xié)議字段(等于6，對TCP)被替換為連接ID，接收方可據此看數個導其代圖5-13。圖5-16中，發(fā)送方調用 press_tcp確認TCP報文段是可壓縮的，函數返回值與數據報首字節(jié)邏輯或后，結果依然保存在首字節(jié)中。圖29-31列出了鏈傳送的前導字節(jié)，其中4位“-”表示正常的IP首部長度字段。7位“C、I、P、S、A、W和E”指明后續(xù)的是哪些可選字段，后面會簡單地介紹這些字母的含 4bit4bit圖29- 圖29-32給出了使用壓縮算法之后，不同類型的完整的IPIPIP數據報的頭協(xié)議 0-65515字節(jié)的IP數 20-60字節(jié)的IP協(xié)議＝TCP 20-60字節(jié)的TCP首 0-65495字節(jié)的TCP數20-60字節(jié)的IP 20-60字節(jié)的TCP首 0-65495字節(jié)的TCP數 0-65495字節(jié)的TCP 3-16字 協(xié)議＝連接TCP非TCP圖29- 采用首部壓縮后的不同類型的IP數據圖中給出了兩個IP型數據報：一個攜帶了非TCP報文段(如UDP、ICMP或IGMP段)，另一個攜帶了TCP報文段。這是為了說明做為IP型數據報發(fā)送的TCP報文段與做為PRESSED_TCP型數據報發(fā)送的TCP報文段間的差異：前導字節(jié)的4比特互不相同，數據報是一個IP分片：分片偏移量非零或者分片標志 、FIN或RST中的任何一個置ACK標志未置位上述3個條件中只要有一個為真，都將作為IP型數據此外，即使數據報攜帶了可壓縮的TCP報文段，壓縮算法也可能失敗，生成PRESSED_TCP型的數據報?？赡芤驗楫斍皵祿笈c連接上發(fā)送的上一個數據報比較時，有些特殊字段發(fā)生了變化，而正常情況下，對于給定的連接，它們應該不變，從而導致壓縮算法無法反映存在的變化。例如，TOS字段，分片標志位。此外，如果某些字段數值的29-33中給出的IP和TCP的首部字段，陰影字段指對于給定連接，正常情況下不會發(fā)生變化的字段。4- 4-版本4- 4-版本 首部長8-服務類型16-bit總長(字節(jié)16-bit標識3-標13-bit8-bit存活時間(8-bit協(xié)16-bit32-bit源IP32-bit目的IP16-bit16-bit32-bit序32-bit4-bit首長保留(6UAPPSFRCSSYIGKHTN16-bit16-bitTCP檢驗16-bit20字20字圖29- 組合的IP和TCP首部：陰影字段通常不變如果連接上發(fā)送的前一個報文段與當前報文段之間，有陰影字段發(fā)生變化，則壓縮算法失敗，報文段被直接發(fā)送。圖中未列出IP和TCP選項，但如果它們存在，且這些選項字段發(fā)生了變化，則報文段也不壓縮，而被直接發(fā)送(習題29.7)。如果陰影字段均未變化，即使算法只傳輸非陰影字段，也會節(jié)省50%的傳輸容量。VJ首最小的壓縮后的IP/TCP首部只有3個字節(jié)：第一個字節(jié)(標志比特)，加上16bit的TCP檢驗和。為了防止可能的鏈路錯誤，一般不改動TCP檢驗和(SLIP不提供鏈路層的檢驗和，盡管 16-bitTCP如果U＝1:TCP如果W＝1:TCP窗口大小差值如果A＝1:TCP確認序號差值圖29-34壓縮后的IP/TCP其他的6個字段：connid、urgoff、win、ack、seq和ipid，都是可選的。圖29-34的最左側列出了各字段壓縮后所需的字節(jié)數。讀者可能認為壓縮后的首部最大應占用19字節(jié)，但實際上壓縮后的首部中4bit的SAWU絕不可能同時置位，因此，壓縮首部最大為16字節(jié)，后面第一個字節(jié)的最比特必須設為1，說明這是COMPRESSED_TCP型的數據報。其余7bit中的6個規(guī)定了后續(xù)首部中存在哪些可選字段，圖29-35小結了這7bit的用法。 標志等于0說標志等于1說連接連接ID不connid=連接ipid=IPPSHseq=TCP序號差ack=TCP確認序號差值urgoff=緊急數據偏移IPip_id已加TCPPSH標志清TCP序th_seq不TCPth_ack不TCP窗TCPth_win不URG標志未置圖29-35壓縮首部中的7C如果C比特等于0，則當前報文段與前一報文段(無論是壓縮的或非壓縮的)具有相同的 如果I比特等于0，當前報文段的IP標識符較前一報文1(典型情況)。如果等于ipid等于ip_id的當前值減去它的前一P這個比特自TCP報文段中的PSH標志位。因為PSH標志不同于其他的正常方式，S如果S比特等于0，TCP序號不變。如果等于1，seq等于th_seq的當前值減去它的前一個值。A如果A比特等于0，TCP確認序號不變(典型情況)。如果等于1，ack等于th_ack的當前W如果W比特等于0，TCP窗口大小不變。如果等于1，win等于th_win的當前值減去U如果U比特等于0，報文段的URG標志未置位，緊急數據偏移量不變(典型情況)等于1URG標志置位，urgoff等于th_urg的當前值。如果URG標志未置位時，緊急數據偏移量發(fā)生改變，報文段將被直接發(fā)送(這種現(xiàn)象通常發(fā)生在緊急數據傳送完畢后的第一個報文段)。通過字段的當前值減去它的前一個值，得到需傳輸的差值。正常情況下，得到的是一個小正數(wi是個例外)。請注意，圖29-34中有5個字段的長度可變，可占用0、1或31字節(jié)：發(fā)送值在1~255之間，只需占用13字節(jié)：如果發(fā)送值等于0或者在26~6535之間，則需要用3個字節(jié)才能表示：第一個字節(jié)全0，后兩個字節(jié)保存實際值。這種方法一般用于3個16biturgoff、n和ipid。但如果兩個32bi字段ack和eq的差值小于0或者大于6553如果把圖93中不帶陰影的字段與圖94中可能的傳輸字段進行比較，會發(fā)現(xiàn)有些字段IP總長度字段不會被傳輸，因為絕大多數鏈路層向接收方提供接收數據分組的長因為IP首部中被傳輸的惟一字段是16bit的IP標識符，IP檢驗和被忽略。因為它只在一算法檢查輸入報文段，如果出現(xiàn)兩種特定情況，則用前導字節(jié)的低位4比特—的兩種特殊組合，分別加以表示。因為緊急數據很少出現(xiàn)，如果報文段中URG標志置位，并且與前一報文段相比，序號與窗口字段都發(fā)生了變化(意味著低位4比特應為1011或1111)， 4比特等于1011(稱為*SA)或SA序號與確認序號都增加，差值等于前一報文段的數據量，窗口大小與緊急數據偏移量不變，URG標志未置位。采用這種表示法可以避免傳送seq和ack。如果對端回送終端數據，那么兩個傳輸方向上的數據報文段中都會經常出現(xiàn)這一現(xiàn)象。卷1的圖19-3和圖19-4，舉例說明了登錄應用中出現(xiàn)的這種類型的數據。S序號增加，差值等于前一報文段的數據量，確認序號、窗口大小與緊急數據偏移量均不變，URG標志未置位。采用這種表示法可以避免傳送seq。這種類型的數據通常出現(xiàn)在單向數據傳輸(如FTP)的發(fā)送方。卷1的圖20-1、圖20-和圖20-3舉例說明了這種類型的數據傳輸。此外，如果對端不回送終端數據，那么在數據發(fā)送方的數據報文段中也會出現(xiàn)這種現(xiàn)象。下面的兩個例子，在圖1-17中的bsdi和slip兩個系統(tǒng)間，利用SLIP鏈路傳輸數據。這條SLIP鏈路在兩個傳輸方向上都采用了首部壓縮算法。在主機bsdi上運行tcpdump程序(卷1的附錄A)，保存所有數據幀的備份。這個程序還支持一個選項，能夠輸出壓縮后的首部，列出圖29-34中的所有字段。在主機間已建立了兩條連接：一條登錄連接，另一條是從bsdi到slip的文件傳(FTP)。圖29-36列出了兩條連接上不同類型數據幀出現(xiàn)的次幀類登輸輸輸輸11553223特殊情況00特殊情況119總圖29-36登錄和FTP連接上，不同類型數據幀出現(xiàn)的次登錄連接中，在兩個傳輸方向上，*SA都出現(xiàn)了75次，從而證明了在對端回顯終端流量時，這一特定