• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            xiaoxiaoling

            C++博客 首頁 新隨筆 聯系 聚合 管理
              17 Posts :: 2 Stories :: 9 Comments :: 0 Trackbacks
            概念
               tcp和udp,連接和無連接都是協議,是共享物理介質的傳輸數據的應用程序之間的約定。面向連接的協議維護了segment的狀態和次序。

            故障 :
                  默認無keep alive:
            拔網線或路由器崩潰:發送端超時(重傳12次大約9分鐘)后放棄,接收端讀errorno ETIMEOUT,如果沒有讀則要等到下一次寫失敗sigpipe。如果中間路由器無法轉發則向源端發送 ICMP 目標主機不可達。
            程序退出(包括崩潰): 程序退出和正常調用 close無法區分,都會返回FIN表示退出,如果一端退出,
                  另一端: 1.第一次寫合法(接收到fin后還是能繼續發送數據)第二次寫的時候發現連接不存在,得到 RST RESET錯誤 2.讀的時候得到 conn reset錯誤,繼續寫則被SIGPIPE信號中止,程序退出。
            主機宕機: 宕機后無法通過FIN通知對方,對方會繼續重傳直到timeout。如果超時前宕機的主機重啟了,此時收到重傳的主機沒有連接記錄,向源返回rst,發送端得到ECONNRESET錯誤,如果發送端在讀得到 conn reset錯誤,繼續寫則被SIGPIPE信號中止,程序退出。
            開啟keep alive情況下:
            如果程序崩潰返回fin , 如果主機可達但程序不存在(主機重啟),則響應RSt,源端得到ECONNRESET 錯誤。
            如果對方沒有對keep alive響應ACK 或者RST,源端TIMEOUT(重試9次,每次間隔75秒,定時器2小時超時后的11.25分鐘)以程序自己做心跳還是必要的。

            細節
            tcp寫操作:
            用戶態拷貝到內核態寫緩沖區后返回,只返回明顯錯誤:socket無效或緩沖區無效。影響的因素有:發送窗口,擁塞窗口,寫緩沖區大小,Nagle。
            tcp是提高帶寬利用率的協議,每次發送傾向mss大小,同時不能大于對端指定的大小(發送窗口),tcp只考慮了網絡中路由器緩沖區耗盡情況(也是tcp的限制)所以有擁塞窗口和慢啟動:為了防止網絡擁塞(自律的協議)每次發送的不能大于對方指定的(發送窗口)和自己給自己限制的(擁塞窗口)。


                

            慢啟動:一開始指數級的增加擁塞窗口,到一個門閥值后變成線性的, 之后每次超時都把門閥值降低到原來一半(并且rto翻倍,TCP超時計算是RTOx2,這樣連續丟三次包就變成RTOx8了,十分恐怖),擁塞窗口設置為1重新開始慢啟動(指數級增加)。一切都是為了讓路由器有時間處理積壓的緩沖。(所以不適用于頻繁斷開連接的移動網絡,這也是為什么以前的下載工具開多條tcp傳輸速度更快的原因)。

            Nagle算法:第一次(此時沒有等待ack確認,空閑連接)發送小包成功,第二次繼續發送 :哪怕發送窗口,擁塞窗口都很大,之前的包沒有ack確認依舊不讓發直到收到之前的 ack確認。

            shutdown和close的區別:

            close只是遞減引用計數, shutdown的半關閉會影響所有的進程。

            shutdown how=0 關閉讀,讀會返回eof
            shutdown how=1 關閉寫,任何寫會出錯,將緩沖區的發送完后會發送fin表示沒有數據了,
            收到對方發送的fin,recv會返回0。
            listen 的第二個參數制定的是全連接隊列大小(accept)

            time_wait和close_wait
            time_wait 出現在主動close方,為了防止新連接收到舊鏈接的數據包, 數量高可以通過設置內核參數縮短時間降低數值(2msl)。可以通過 SO_LINGER關閉。
            close_wait 出現在被動close方,數量高一般因為性能或者bug在收到fin后沒有調用close。

            SO_REUSEADDR
            用于程序崩潰后重啟,解決地址被占用問題(time_wait),另一個用途是開兩個服務,第一個制定地址,第二個指定INADDR_ANY 通配地址,如果客戶端連接的是制定地址一樣會到第一個socket上。
                  對于綁定于同一地址端口組合上的UDP socket,kernel嘗試在它們之間平均分配收到的數據包;對于綁定于同一地址端口組合上的TCP監聽socket,kernel嘗試在它們之間平均分配收到的連接請求(調用accept()方法所得到的請求)。

            Nagle和延遲ack的問題:
            發送端數據未發送完,被nagle禁止發送(必須等待接收端的ack,也就是沒有未確認的包才允許發送),此時接收端ack被延遲發送(希望將ack和數據一起發送提高帶寬利用率)而發送方數據未發送完導致接收端無法回復,雙方死鎖。
            已連接的UDP:
            tcp的connect是開始三次握手,將遠程的ip端口綁定到socket,而bind是綁定本地的ip端口。
            udp沒有三次握手,connect純粹是本地行為,將遠程的ip端口綁定到socket上。
            已連接的udp可以不用sendto,sendto會先將socket和目的地址連接,然后發送數據后再斷開,而已連接的已經綁定地址可以用write,提高效率(資料顯示暫時連接斷開所用的時間是傳輸udp數據的三分之一,還是很可觀的)。異步錯誤的接收,使用sendto發送完系統就沒有記錄了,應用程序無法接收之后icmp返回的錯誤。
            接收端已連接udp的好處: 可以標識哪個socket是哪個用戶,另外還可以獨占連接,再另一個地方調用recvfrom指定相同地址會返回ECONNREFUSED,因為此連接已經被綁定。
            posted on 2018-07-13 15:49 clcl 閱讀(270) 評論(0)  編輯 收藏 引用
            亚洲精品乱码久久久久久不卡| 久久综合亚洲色HEZYO国产| 一本久久免费视频| 久久精品免费全国观看国产| 亚洲精品美女久久久久99| 久久久久久久尹人综合网亚洲| 久久se这里只有精品| 久久受www免费人成_看片中文| 亚洲AV无码久久精品色欲| 久久亚洲精品中文字幕三区| 热久久最新网站获取| 久久99精品久久久久久| 女同久久| 狠狠综合久久综合中文88| 性欧美丰满熟妇XXXX性久久久| 99久久精品国产综合一区| 亚洲va中文字幕无码久久不卡 | 69国产成人综合久久精品| 久久九色综合九色99伊人| 精品久久久无码人妻中文字幕豆芽 | 久久91精品综合国产首页| 一本久久a久久精品vr综合| 久久久久久A亚洲欧洲AV冫| 精品永久久福利一区二区| 久久无码AV中文出轨人妻| 91精品国产色综久久| 久久99精品久久久久久久久久| 日韩精品久久久久久久电影| 久久天天躁狠狠躁夜夜av浪潮| 91麻精品国产91久久久久| 久久se精品一区二区| 久久精品无码专区免费青青| 777午夜精品久久av蜜臀| 综合久久国产九一剧情麻豆| 久久国产AVJUST麻豆| 久久久精品久久久久影院| 久久久WWW成人免费精品| 久久精品国产99久久香蕉| 国产激情久久久久影院老熟女免费| 国产亚洲欧美成人久久片| 久久99精品国产|