容器訪問應(yīng)用服務(wù)不通問題排查

問題的起點(diǎn)

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

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

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

排查過程

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

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

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

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

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

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

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

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

• 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)連接的時(shí)間戳小于 路由中保存的時(shí)間戳；

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

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

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

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

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

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

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

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

通過上面分析，問題明顯和tcp timestmap有關(guān)，發(fā)現(xiàn)tcp_tw_recycle/tcp_timestamps都開啟的條件下，60秒內(nèi)同一源ip主機(jī)的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選項(xiàng)
TCP_PAWS_MSL：60s，該條件判斷表示該源ip的上次tcp通訊發(fā)生在60s內(nèi)
TCP_PAWS_WINDOW：1，該條件判斷表示該源ip的上次tcp通訊的timestamp大于本次tcp

Tcp_timestamp 是 RFC1323 定義的優(yōu)化選項(xiàng)，主要用于 TCP 連接中 RTT(Round Trip Time) 的計(jì)算，開啟 tcp_timestamp 有利于系統(tǒng)計(jì)算更加準(zhǔn)確的 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會(huì)啟用tcp time_wait的快速回收，這個(gè)參數(shù)不建議在NAT環(huán)境中啟用，它會(huì)引起相關(guān)問題。

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

解決方案

有兩個(gè)方案可選：

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

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

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

因?yàn)樵趖cp timestamp關(guān)閉的條件下，開啟tcp_tw_recycle是不起作用的；而tcp timestamp可以獨(dú)立開啟并起作用。所以建議服務(wù)關(guān)閉tcp_tw_recycle.

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

1、臨時(shí)關(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)多個(gè)客戶端同時(shí)使用同一個(gè)IP訪問同一個(gè)服務(wù)端的場景要在服務(wù)端關(guān)閉tcp_tw_recycle。如以下場景：

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

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

3、ECS通過公網(wǎng)地址，NAT網(wǎng)關(guān)和EIP直接提供服務(wù)的。因?yàn)橛捎谀壳癐PV4地址枯竭，絕大部分的客戶端都是使用SNAT進(jìn)行訪問。

附錄

參考：

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