1. 首頁 > 生活百科 > >

手機網絡請求超時怎么解決 請求超時怎么解決手機

生活百科

請求超時怎么解決,手機,手機網絡請求超時怎么解決 。小編來告訴你更多相關信息 。
為了簡化描述，我們先考慮沒有啟用tcp_syncookies的情況 。
三次握手的狀態圖，從用戶態的視角如下：

手機網絡請求超時怎么解決 請求超時怎么解決手機

文章插圖
手機網絡請求超時怎么解決 請求超時怎么解決手機

文章插圖
本篇文檔中，只描述服務器側的處理 。當server端調用listen()設置監聽端口時，服務器端是會預先建立兩個隊列，而這兩個隊列是用來完成三次握手的整個過程的 。在用戶沒有調用accept時，就有可能三次握手已經完成，圖1中的后兩個包的交互過程是由內核來完成的 。因此需要用戶調用accept之前，就能管理這些收到的syn包，和已經完成建議連接的socket 。
兩個隊列分別是：
request_sock_queue->listen_sock->syn_table:(命名為半連接隊列)
request_sock_queue->request_sock_queue（命名為全連接隊列）
【手機網絡請求超時怎么解決 請求超時怎么解決手機】當調用listen()函數時，就已經對這兩個隊列的長度進行了限定 。
半連接隊列：min(backlog,
somaxconn, tcp_max_syn_backlog)
全連接隊列：min(backlog,somaxcon)
當服務器端收到一個syn請求時，會將相應的syn請求放到半連接隊列中，syn請求在內核中是以數據結構request_sock來表示的 。
函數調用關系如下：
tcp_rcv_state_process（）
|switch(sk->state)
|case TCP_LISTEN: // We received SYN
|conn_request -> tcp_v4_conn_request
tcp_v4_conn_request()中
1．首先判斷半連接隊列是否已滿 。若滿，則并輸出告警信息 。possible SYN flooding on port…
2．判斷全連接隊列是否已滿 。若滿，則丟棄這個請求 。
3．處理syn的option 。
4．創建syn的ack包，并發送 。
5．將syn的request_sock加到半連接隊列中 。
當服務器端收到三次握手的最后一個ACK時，會創建一個獨立完整的socket，放到全連接隊列中 。同時將半連接中的request_sock刪除掉 。新的socket等待accept的調用 。函數調用關系如下：
tcp_v4_do_rcv()
|case TCP_LISTEN:
tcp_v4_hnd_req
|inet_csk_search_req
tcp_check_req // update request_sock to icsk_accept_queue
|syn_recv_sock -> tcp_v4_syn_recv_sock //create clild socket.
| inet_csk_reqsk_queue_unlink//將request_sock從半連接隊列中刪除
| inet_csk_reqsk_queue_removed//更新計數值
| inet_csk_reqsk_queue_add//將新建的socket放到全連接隊列中
tcp_v4_syn_recv_sock()是核心函數：
1.調用sk_acceptq_is_full來判斷全隊列是否已經滿 。隊列最大長度是sk_max_ack_backlog(即min(backlog,somaxcon))，這個是在listen時，確定下來的 。如果溢出，增加ListenOverflows計數值，并且丟棄這個應答包 。
2.創建一個新的socket，并進行初始化 。
從以上可以得知，如果出現ListenOverFlow這個值的增加，則對用戶的影響是很大的 。因為從三次握手流程可以看到，從客戶端發送SYN包開始收到最后一個ACK被丟棄，經歷了1.5個RTT時間 。對于延時很大的網絡，比如跨國際網絡，移動網絡等高延時網絡，以400ms的RTT計算 。假設第一次重傳后則成功完成了連接 。則總共開銷時間是RTT*400ms+RTO=3.4s 。（RTO：超時時間 。Window系列，linux系列都是3s的超時時間） 。系統中有一個參數tcp_abort_on_overflow，這個參數默認值是0，表示不啟用 。如果開啟的話，出現全連接隊列溢出時，則不是無聲的丟棄收到的包，而是發送RESET包終止這個連接 。
對于啟用tcp_syncookies的時候，是怎么處理的呢？當前系統下，默認是開啟這個功能的 。因此更有必要了解下這個功能的作用，處理邏輯 。之前已經了解到收到syn包后，我們會在內核中建立一個數據結構來管理這個syn包 。如果有大量請求的話，半連接隊列會被撐爆 。
考慮極端情況，隊列長度無限，則內核耗光；syn攻擊，正常請求會被排除在半連接隊列之外，正常的訪問會受到影響 。Syncookie就是解決這個問題的 。啟用syn cookie的話，理論上是沒有隊列長度的 。Syn cookie的工作原理是：
1.當收到syn請求后，如果半連接隊列未滿，則與上述相同的處理邏輯 。如果滿了，則不會丟棄這個syn請求，而是根據4元組（源地址，源端口，本地地址，本地端口），MSS選項和當前時間來計算出一個新的序列號，這個序列號就是syn+ack包的序列號 。同時不新建一個結構來保存收到的syn請求 。
2.如果收到ACK包，則會對收到的應答包的應答序列號進行驗證 。驗證的方法是先得到之前發送的序列號 。直接將應答序列號減1就可以了 。有專門的解密函數，來解密這個序列號中所包含的時間信息，端口等信息 。驗證成功，則完成三次握手 。否則，則丟棄這個包 。

推薦閱讀