問題的起點

1、用戶反饋同個ECS啟動了多個容器，其中一個容器無法與Anytunnel 100.64.0.1通信，TCP建聯(lián)失敗。不通的容器IP是172.16.0.13。其他能通的容器比如 172.16.0.15。

作為一家“創(chuàng)意+整合+營銷”的成都網(wǎng)站建設(shè)機構(gòu)，我們在業(yè)內(nèi)良好的客戶口碑。成都創(chuàng)新互聯(lián)公司提供從前期的網(wǎng)站品牌分析策劃、網(wǎng)站設(shè)計、成都網(wǎng)站設(shè)計、成都網(wǎng)站制作、創(chuàng)意表現(xiàn)、網(wǎng)頁制作、系統(tǒng)開發(fā)以及后續(xù)網(wǎng)站營銷運營等一系列服務(wù)，幫助企業(yè)打造創(chuàng)新的互聯(lián)網(wǎng)品牌經(jīng)營模式與有效的網(wǎng)絡(luò)營銷方法,創(chuàng)造更大的價值。

2、在Anytunnel 100.64.0.1的后端RS上抓包，發(fā)現(xiàn)有172.16.0.13 TCP 建聯(lián)成功的的記錄。說明有其他VPC也有用172.16.013地址來訪問，并且是通的。

PS:AnyTunnel地址指的是每個VPC中100.64.0.0/10內(nèi)的地址，用于VPC中DNS、YUM、NTP、OSS或SLS等云服務(wù)中使用。簡單可以理解為在VPC下為了解決不同VPC內(nèi)網(wǎng)互通的特殊的SLB。這個SLB能被同個Region下所有的VPC訪問。

排查過程

1、首先我們要確定VPC1下172.16.0.13的請求有沒有到達AnyTunnel后端RS上，最簡單的方法就是在172.16.0.13和后端RS上同時抓包進行分析。

客戶端和RS上抓包通過“tcp.analysis.retransmission”條件過濾出有問題的重傳報文，發(fā)都是SYN的重傳。

重傳報文數(shù)量都是7個，并且源端口一致，那么說明請求報文已經(jīng)到達RS上，但是RS沒有響應(yīng)SYN-ACK，導(dǎo)致TCP建聯(lián)失敗。

2、在RS上查看TCP計數(shù)發(fā)現(xiàn)：

netstat?-ts?|grep?SYNs???
3631812?SYNs?to?LISTEN?sockets?dropped

有大量tcp syn包被丟棄，數(shù)值一直在增長，進一步說明是RS收到客戶端的SYN請求但是沒有響應(yīng)。

為何RS沒有響應(yīng)SYN請求分析

netstat中的計數(shù)統(tǒng)計，里面定義了TCP連接失敗統(tǒng)計，具體如下：

• resets received for embryonic SYN_RECV sockets? ---syn_recv狀態(tài)下，收到非重傳的syn包，則返回reset

• passive connections rejected because of time stamp ---開啟sysctl_tw_recycle，syn包相應(yīng)連接的時間戳小于 路由中保存的時間戳；

• failed connection attempts --- syn_recv狀態(tài)下，socket被關(guān)閉， 或者收到syn包（非重傳）

• times the listen queue of a socket overflowed? ---收到三次握手ack包，accept隊列滿

• SYNs to LISTEN sockets ignored ---收到三次握手ack包，因各種原因（包括accept隊列滿） 創(chuàng)建socket失敗

通過netstat -ts查看到passive connections rejected because of time stamp統(tǒng)計數(shù)值非常大，并且接近于SYNs to LISTEN sockets dropped的數(shù)量。

3631476?passive?connections?rejected?because?of?time?stamp

說明就是由于syn包相應(yīng)連接的時間戳問題導(dǎo)致的。

于是再次分析RS的抓包文件：

報文序列	是否成功響應(yīng)SYN	TimeStamp值
1	成功響應(yīng)SYN	2088983548
2	沒有響應(yīng)SYN	271344470
3	沒有響應(yīng)SYN	271345544
4	沒有響應(yīng)SYN	271346612
5	沒有響應(yīng)SYN	271348509
6	沒有響應(yīng)SYN	271351766
7	成功響應(yīng)SYN	2088993553

從抓包信息里可以看出，當(dāng)后面的SYN報文的TimeStamp值小于前面成功響應(yīng)的SYN報文的TimeStamp值，系統(tǒng)默認就會不響應(yīng)該SYN請求。

通過上面分析，問題明顯和tcp timestmap有關(guān)，發(fā)現(xiàn)tcp_tw_recycle/tcp_timestamps都開啟的條件下，60秒內(nèi)同一源ip主機的socket connect請求中的timestamp必須是遞增的。

源碼函數(shù)：tcp_v4_conn_request(),該函數(shù)是tcp層三次握手syn包的處理函數(shù)（服務(wù)端）；
????源碼片段：
???????if?(tmp_opt.saw_tstamp?&&
????????????tcp_death_row.sysctl_tw_recycle?&&
????????????(dst?=?inet_csk_route_req(sk,?req))?!=?NULL?&&
????????????(peer?=?rt_get_peer((struct?rtable?*)dst))?!=?NULL?&&
????????????peer->v4daddr?==?saddr)?{
????????????if?(get_seconds()?<?peer->tcp_ts_stamp?+?TCP_PAWS_MSL?&&
????????????????(s32)(peer->tcp_ts?-?req->ts_recent)?>
????????????????????????????TCP_PAWS_WINDOW)?{
????????????????NET_INC_STATS_BH(sock_net(sk),?LINUX_MIB_PAWSPASSIVEREJECTED);
????????????????goto?drop_and_release;
????????????}
????????}
????????
tmp_opt.saw_tstamp：該socket支持tcp_timestamp
sysctl_tw_recycle：系統(tǒng)開啟tcp_tw_recycle選項
TCP_PAWS_MSL：60s，該條件判斷表示該源ip的上次tcp通訊發(fā)生在60s內(nèi)
TCP_PAWS_WINDOW：1，該條件判斷表示該源ip的上次tcp通訊的timestamp大于本次tcp

Tcp_timestamp 是 RFC1323 定義的優(yōu)化選項，主要用于 TCP 連接中 RTT(Round Trip Time) 的計算，開啟 tcp_timestamp 有利于系統(tǒng)計算更加準確的 RTT，也就有利于 TCP 性能的提升。

tcp_tw_recycle?(Boolean;?default:?disabled;?since?Linux?2.4)
??????????????Enable?fast?recycling?of?TIME_WAIT?sockets.??Enabling?this?option?is?not?recommended?since?this?causes?problems?when?working?with?NAT?(Network?Address
??????????????Translation).

開啟tcp_tw_recycle會啟用tcp time_wait的快速回收，這個參數(shù)不建議在NAT環(huán)境中啟用，它會引起相關(guān)問題。

官方定義是在NAT環(huán)境中使用會引發(fā)問題，但是歸根結(jié)底就是多個客戶端使用同個地址訪問服務(wù)端會出現(xiàn)該問題。我們的問題符合該場景。

解決方案

有兩個方案可選：

• 客戶端關(guān)閉tcp_timestamps,將該值設(shè)置為0.

• 服務(wù)器端不要將tcp_tw_recycle字段和tcp_timestamps字段同時設(shè)為1?

由于客戶端掌握在客戶的手里，我們無法掌握到每個客戶端的配置，所以還是需要服務(wù)端進行配置。

因為在tcp timestamp關(guān)閉的條件下，開啟tcp_tw_recycle是不起作用的；而tcp timestamp可以獨立開啟并起作用。所以建議服務(wù)關(guān)閉tcp_tw_recycle.

服務(wù)端（RS端）關(guān)閉tcp_tw_recycle具體操作方法。

1、臨時關(guān)閉方法：
echo?"0"?>?/proc/sys/net/ipv4/tcp_tw_recycle

2、永久關(guān)閉方法：
在?/etc/sysctl.conf?文件中添加?net.ipv4.tcp_tw_recycle?=?0
然后使用?sysctl?-p?命令讓配置文件生效

引伸

根據(jù)上面的原理，出現(xiàn)多個客戶端同時使用同一個IP訪問同一個服務(wù)端的場景要在服務(wù)端關(guān)閉tcp_tw_recycle。如以下場景：

1、同一個Client訪問四層私網(wǎng)SLB的同時，還有繞過SLB直接訪問SLB后端ECS

2、相同的ECS同時掛在多個四層SLB之后，并且同一個客戶端有同時或者連續(xù)訪問多個SLB

3、ECS通過公網(wǎng)地址，NAT網(wǎng)關(guān)和EIP直接提供服務(wù)的。因為由于目前IPV4地址枯竭，絕大部分的客戶端都是使用SNAT進行訪問。

附錄

參考：

http://blog.sina.com.cn/s/blog_781b0c850101pu2q.html

分享名稱：容器訪問應(yīng)用服務(wù)不通問題排查
分享路徑：http://jinyejixie.com/article36/gpedpg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站策劃、ChatGPT、自適應(yīng)網(wǎng)站、搜索引擎優(yōu)化、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)