2. 程式人生 > >Linux下超時重傳時間(RTO)的實現探究

Linux下超時重傳時間(RTO)的實現探究

阿新 • • 發佈：2019-01-23

最近出現了網路超時的問題要排查，大致按照如圖思路去排查

分層圖

1.排除程式碼邏輯問題，TCP相關可能的BUG，核心引數等問題；

2.排查KVM問題時，在同一個宿主機的不同KVM上，復現了超時問題。

發現大部分異常連線時長都在1s左右，通過抓包分析，可以看到這部分的包被重傳了，重傳的時間固定為1秒。

這裡重傳時間為什麼是1秒呢，相關的標準和實際實現是怎樣的呢？

本文主要討論的就是這部分內容（基於centos的2.6.32-358）

RFC標準

超時重傳時間（RTO）是由當前網路狀況（RTT），然後根據一個演算法來決定。這部分相關內容《TCP/IP詳解卷1》中有提到，但是已經過時了。

去RFC查了下，重傳超時相關最新的是RFC6298，他更新了RFC1122並且廢棄了RFC2988

稍微介紹一下其中內容，有興趣的可以點進去看

1 重申了RTO的基本計算方法：

首先有個通過時鐘得到的時間引數RTO_MIN

初始化：

第一次計算：

以後的計算：

RTO的最小值建議是1秒，最大值必須大於60秒

2 對於同一個包的多次重傳，必須使用Karn演算法，也就是剛才看到的雙倍增長

另外RTT取樣不能使用重傳的包，除非開啟了timestamps引數（利用該引數可以準確計算出RTT）

3 當4*RTTVAR趨向於0時，得到的值必須向RTO_MIN時間靠近

經驗上時鐘越準確越好，最好誤差在100ms內

4 RTO計時器的管理

（1）傳送資料（包括重傳時），檢查計時器是否啟動，若沒有則啟動。當收到該資料的ACK時刪除計時器

（2）使用RTO = RTO * 2的方式進行退避

（3）新的FALLBACK特性：當計時器在等待SYN報文時過期，且當前TCP實現使用了小於3秒的RTO，那麼該連線對的RTO必須被重設為3秒，重設的RTO將用在正式資料的傳輸上（就是三次握手結束以後）

對linux的實際實現進行抓包分析

三次握手的syn包傳送

1 2 3 4 5 6 01:00:00.129688 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
01:00:01.129065 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:00:03.129063 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:00:07.129074 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:00:15.129072 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:00:31.129128 IP 172.16.3.14.1868 > 172.16.10.40.80: Flags [S], seq 3774079837, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

從1秒起雙倍遞增

值得注意是實質上第五次超時以後等到第六次，才會通知上層連線超時，那一共是63秒

三次握手的syncak包傳送

1 2 3 4 5 6 7 01:17:20.084839 IP 172.16.3.15.2535 > 172.16.3.14.80: Flags [S], seq 1297135388, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:20.084908 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:21.284093 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:23.284088 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:27.284095 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:35.284097 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 01:17:51.284093 IP 172.16.3.14.80 > 172.16.3.15.2535: Flags [S.], seq 1194120443, ack 1297135389, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

從1秒起雙倍遞增

正常的資料包傳送

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 01:32:20.443757 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:20.644600 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:21.046579 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:21.850632 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:23.458555 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:26.674594 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:33.106601 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:32:45.970567 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:33:11.698415 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:34:03.154300 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:35:46.065892 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:37:46.065382 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:39:46.064917 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:41:46.064466 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:43:46.064060 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11 01:45:46.063675 IP 172.16.3.15.2548 > 172.16.3.14.80: Flags [P.], seq 3319667389:3319667400, ack 1233846614, win 115, length 11

從0.2秒起雙倍遞增，最大到120秒，一共15次

值得注意的是從32分開始，47分才結束，也就是15分鐘25秒左右

linux是否支援了FALLBACK特性，做一個簡單的測試

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 server開啟iptables後，client連線server，在5次超時次數內關閉iptables 23:35:01.036565 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 23:35:02.036152 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 23:35:04.036126 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 23:35:08.036127 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 23:35:16.036131 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [S], seq 2364912154, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 23:35:16.036842 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [S.], seq 3634006739, ack 2364912155, win 14600, options [mss 1460], length 0 23:35:16.036896 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [.], ack 3634006740, win 14600, length 0 接著server開啟iptables後，client傳送資料包，在15次超時次數內關閉iptables 23:35:48.129273 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1 23:35:51.129120 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1 23:35:57.129070 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1 23:36:09.129068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912155:2364912156, ack 3634006740, win 14600, length 1 23:36:09.129802 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [.], ack 2364912156, win 14600, length 0 接著server不開iptables時，client傳送資料包 23:36:15.217231 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912156:2364912157, ack 3634006740, win 14600, length 1 23:36:15.217766 IP 172.16.10.40.12345 > 172.16.3.14.6071: Flags [.], ack 2364912157, win 14600, length 0 接著server開啟iptables，client傳送資料包 23:36:26.658172 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:26.859055 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:27.261065 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:28.065106 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:29.673132 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:32.889068 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:39.321091 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:36:52.185135 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1 23:37:17.913091 IP 172.16.3.14.6071 > 172.16.10.40.12345: Flags [P.], seq 2364912157:2364912158, ack 3634006740, win 14600, length 1

從這個測試中可以發現，當三次握手時RTT超過1秒時，資料傳送階段的RTO為3秒（服務端的SYNACK發生超時也是如此）

而後正常的一次RTT後，RTO重新收斂到200ms左右

再看看timestamps的支援如何

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 server開啟iptables後，client連線server，在5次超時次數內關閉iptables 23:47:47.754316 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336007392 ecr 0,nop,wscale 7], length 0 23:47:48.754079 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336008392 ecr 0,nop,wscale 7], length 0 23:47:50.754088 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336010392 ecr 0,nop,wscale 7], length 0 23:47:54.754083 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336014392 ecr 0,nop,wscale 7], length 0 23:48:02.754094 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [S], seq 479022248, win 14600, options [mss 1460,sackOK,TS val 2336022392 ecr 0,nop,wscale 7], length 0 23:48:02.754683 IP 172.16.10.40.12345 > 172.16.3.14.8603: Flags [S.], seq 697602971, ack 479022249, win 14480, options [mss 1460,nop,nop,TS val 4044659641 ecr 2336022392], length 0 23:48:02.754742 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [.], ack 697602972, win 14600, options [nop,nop,TS val 2336022392 ecr 4044659641], length 0 接著server開啟iptables後，client傳送資料包，在15次超時次數內關閉iptables 23:48:11.944170 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336031582 ecr 4044659641], length 1 23:48:12.145036 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336031783 ecr 4044659641], length 1 23:48:12.547084 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336032185 ecr 4044659641], length 1 23:48:13.351106 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336032989 ecr 4044659641], length 1 23:48:14.959080 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336034597 ecr 4044659641], length 1 23:48:18.175092 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336037813 ecr 4044659641], length 1 23:48:24.607088 IP 172.16.3.14.8603 > 172.16.10.40.12345: Flags [P.], seq 479022249:479022250, ack 697602972, win 14600, options [nop,nop,TS val 2336044245 ecr 4044659641], length 1

可以看到開啟了timestamps後，FALLBACK機制重設RTO為3秒將不會起作用

linux的對RTO計算的微調

linux對RTO計算的實際實現和RFC文件相比還是有所出入的，如果只按照RFC文件去按圖索驥，那麼在實際的RTO估計上會誤入歧途

1 根據上一段可以發現，他把RTO的最小值設為200ms（甚至在ubuntu上是50ms，而RFC建議1秒），最大值設定為120秒（RFC強制60秒以上）

2 根據我對linux程式碼的分析，在RTT劇烈抖動的情況下，linux的實現減輕了急劇改變的RTT干擾，使得RTO的趨勢圖更加平滑

這一點體現在兩點微調上：

微調1

當滿足以下條件時

說明R'的波動太大了，和平滑過的RTT值比，差值的比RTTVAR還大

於是

而RFC文件是

可以看到，和RFC文件相比平滑係數乘以了1/8，表示R'對RTTVAR的影響將減小，使得RTTVAR更平滑，RTO也會更平滑

微調2

當RTTVAR減少的時候，會對RTTVAR做一次平滑處理，使得RTO不會下降的太離譜出現陡峭的趨勢圖

這裡RTTVAR'指的是當前根據RTT計算得到的值，這個值限制了下限(RTO_MIN)以後和上一個RTT時的RTTVAR比較，當發現減少時，使用1/4係數來做平滑處理

這裡為什麼不對增大的情況做處理呢？我認為是因為RTO增大的話其實沒事，但是如果減少量很大的話，可能會引起spurious retransmission（關於這個名詞，詳細見上文提到的RFC文件）

人為介入修改RTO的方法

回到最初的問題，是否能縮短RTO的值，而且這個RTO值如何根據linux的實際實現去預估

顯然RTO初始值（包括FALLBACK）是不能改變的，這部分是固死寫在程式碼裡的

而三次握手以外的RTO值是可以預估的

預估時假設網路穩定，RTT始終不變為R（否則由於微調1和2，將極其複雜）

那麼SRTT將始終為R,RTTVAR將始終為0.5R

否則

因此只需要改變RTO_MIN的值，就能顯著影響RTO的值

RTO_MIN的設定

RTO_MIN的設定是根據ip route來實現的

1 2 3 4 5 6 7 8 9 10 11 12 13 [[email protected] ~]# ping www.baidu.com PING www.a.shifen.com (180.97.33.107) 56(84) bytes of data. 64 bytes from 180.97.33.107: icmp_seq=1 ttl=51 time=30.8 ms 64 bytes from 180.97.33.107: icmp_seq=2 ttl=51 time=29.9 ms 獲得百度的IP後 [[email protected] ~]# ip route add 180.97.33.108/32 via 172.16.3.1 rto_min 20 [[email protected] ~]# nc www.baidu.com 80 [[email protected] ~]# ss -eipn '( dport = :www )' State       Recv-Q Send-Q                                                              Local Address:Port                                                                Peer Address:Port ESTAB       0      0                                                                     172.16.3.14:14149                                                              180.97.33.108:80     users:(("nc",7162,3)) ino:48057454 sk:ffff88023905adc0 sack cubic wscale:7,7 rto:81 rtt:27/13.5 cwnd:10 send 4.3Mbps rcv_space:14600

因為RTO_MIN < 2R，所以RTO = 3R = 27 * 3 = 81

如果是內網的話，RTT非常小

1 2 3 4 5 6 7 [[email protected] ~]# ip route add 172.16.3.16/32 via 172.16.3.1 rto_min 20               [[email protected] ~]# nc 172.16.3.16 22 SSH-2.0-OpenSSH_5.3 [[email protected] ~]# ss -eipn '( dport = :22 )' State       Recv-Q Send-Q                                                              Local Address:Port                                                                Peer Address:Port ESTAB       0      0                                                                     172.16.3.14:57578                                                                172.16.3.16:22     users:(("nc",7272,3)) ino:48059707 sk:ffff88023b7c7000 sack cubic wscale:7,7 rto:21 rtt:1/0.5 ato:40 cwnd:10 send 116.8Mbps rcv_space:14600

因為RTO_MIN > 2R，所以RTO = R + RTO_MIN = 1 + 20 = 21

如果對內網的整個網路有自信的話，也可以不設定目標IP，直接對全部連線生效，如下

1 ip route change dev eth0 rto_min 20ms

總結

1 linux的超時重傳實現大體上參考了RFC，但是有一部分微調：

RFC只有一個RTO初始值，為1秒。而linux的實現將三次握手階段的包的RTO設為1秒，其餘包初始時間設為0.2秒

由於RFC規定的演算法不夠完美，linux的實際實現在RTT劇烈抖動的情況下，減輕了急劇改變的RTT干擾，使得RTO的趨勢圖更加平滑

2 連線的SYN重傳時間，在除非重新編譯核心的情況下是無法調整的，但是push包是可以調整重傳時間的

3 在比較穩定的網路中，假設設定的rto最小值為RTO_MIN

4 以行動網路客戶端作為服務物件的伺服器端，由於平均網路質量較差，調大RTO_MIN的值或許能減輕伺服器的壓力，具體值需要根據實際情況調整

5 在內網環境中，在KVM出現IO效能問題時，調小RTO_MIN的值或許能減少PUSH包的超時時間，但是會顯著增加重傳包的數目，可能會因為加重了KVM的負載反而使得情況惡化，所以具體值也需要根據實際情況調整

相關推薦

Linux下超時重傳時間(RTO)的實現探究

最近出現了網路超時的問題要排查，大致按照如圖思路去排查 1.排除程式碼邏輯問題，TCP相關可能的BUG，核心引數等問題； 2.排查KVM問題時，在同一個宿主機的不同KVM上，復現了超時問題。 發現大部分異常連線時長都在1s左右，通過抓包分析，可以看到這部分的包被重傳了，重

TCP的超時重傳之深入瞭解RTT與RTO

TCP提供一種面向連線的、可靠的位元組流服務，其中可靠的保證方法之一就是卻讓從另一端收到的資料。但是資料和確認訊號都有可能丟失，。TCP通過在傳送資料時設定一個重傳定時器（注意這裡的超時定時器和第四節講的定時器不一樣）來監控資料的丟失狀態，如果重傳定時器溢位時還

【原創】TCP超時重傳機制探索

sender mic borde 做了 5.5 多次 字節 應用程序 實現 TCP超時重傳機制探索作者：tll （360電商技術）1）通信模型TCP（Transmission Control Protocol）是一種可靠傳輸協議。在傳輸過程中當發送方（sender）向接

Linux下批量重命名的方法

rename name 文件 -a 舉例 創建 doc tex 正則 rename 1.不過它要用 perl 正則表達式來作為參數， 2.舉例如下： touch test{1..5}.txt ##使用通配符創建5個文件 rename ‘s/\.txt/\.doc/‘

Linux下Shell重定向

amp 操作 tab /dev/ 輸出重定向 esc /etc cal 信息 1. 標準輸入，標準輸出與標準錯誤輸出 Linux下系統打開3個文件，標準輸入，標準輸出，標準錯誤輸出。 標準輸入:從鍵盤輸入數據，即從鍵盤讀入數據。 標準輸出:把數據輸出到終端上。 標準錯誤輸出

linux下如何修改系統時間

linux下如何修改系統時間 我們一般使用“date -s”命令來修改系統時間。比如將系統時間設定成2018年2月23日的命令如下。 　　　　#date -s 02/23/2018　　　　將系統時間設定成下午11點12分0秒的命令如下。　　　　#date -s 11:12:00　　　　註意，這裏說的是系統

Linux下多節點SSH無密碼互聯實現

openssh color pre 都是 測試 創建 私鑰 無密碼ssh 需要 需求：有3個主機192.168.0.191、192.168.0.192、192.168.0.193，需要實現無密碼ssh互聯訪問 我使用的是root用戶進行操作的： 1、每個節點分別檢查是否安裝

Linux 下MySql 重置密碼

ted 停止 serve 0 rows with 設置 root密碼 bin 數據庫完全 1．首先確認服務器出於安全的狀態，也就是沒有人能夠任意地連接MySQL數據庫。 因為在重新設置MySQL的root密碼的期間，MySQL數據庫完全出於沒有密碼保護的 狀態下，其他

linux下tomcat重啟腳本(使用tomcat.pid)(推薦)

sleep gdi app bin server 進程 ash webapps 重啟 1、配置tomcat啟動後將進程號保存至$TOMCATHOME/bin/tomcat.pid文件。 修改$TOMCAT_HOME/bin/catalina.sh文件，在PRGDIR下面一行

linux下檔案的建立時間、訪問時間、修改時間和改變時間

   Linux系統中沒有命令可以確切的檢視一個檔案的生成時間，但是可以知道訪問時間，修改時間，改變時間。 可以通過stat命令檢視一個檔案的訪問時間，修改時間，改變時間： 以下為三個時間的區別： 1、訪問時間（accesstime）：讀取一次檔案的內容，該時間

TCP超時重傳機制

TCP協議在能夠傳送資料之前就建立起了“連線”。要實現這個連線，啟動TCP連線的那一方首先將傳送一個SYN資料包。這只是一個不包含資料的資料包， 然後，開啟SYN標記。如果另一方同時在它收到SYN標記的埠通話，它將發回一個SYN+ACK:SYN和ACK標誌位都被開啟，並將A

【轉載】linux下安裝wget命令（sftp實現法）

 如何安裝wget命令。 方法一：通過yum 命令列為：yum install wget 完成。此操作很簡單，但是我安裝的linux是centos的最小版本，執行上述命令時會出現無法連線到源網站（大概是這個意思）的問題。 方法二：通過rpm 據說rpm是linux的通用安裝法，小白表示不懂

linux 下正則匹配時間命名格式的文件夾

class path 目錄 正則 正則表達式 中間 gre 文件 pat 用正則表達式匹配時間格式命名的文件夾 ls mypath | grep -E "[0-9]{4}-[0-9]{1,2}" mypath為需要查詢的目錄 查詢出來的文件夾格式為：例 2018-12

linux下c語言利用iconv函式實現utf-8轉unicode

    由於專案中需要轉換原生unicode到ascii的功能，本來想的用的是linux或者windows自帶的寬位元組轉成窄位元組的函式，但由於本身使用了apr_iconv庫，所以直接使用庫函式來解決。     期間碰到了庫函式使用一直出錯的問題，一

Linux下—mysql資料庫的多例項實現

準備環境： centos7 安裝 yum install mariadb-server 規劃實現多例項的目錄結構、 埠：3306,3307, 3308 每個例項存放資料庫的資料夾 /data/mysql{3306,3307,3308} /data/mysql/3306/{etc,

超時重傳+擁塞控制

超時重傳+擁塞控制 https://www.cnblogs.com/alva-rabbit-hole/p/10086939.html 超時重傳 上一篇文章裡介紹過TCP採用停止等待協議，即在收到接收方的確認資訊後才繼續傳送下面的資料。 那麼如果（在一段時間內）傳送方沒有收到確認資訊，我們便可以認為資料在傳

linux下執行連結串列棧（實現棧的基本功能 push，pop，刪除任意結點，遍歷輸出等）

一、簡要敘述設計思想和技術路線（不少於300字）（20分）。 設計思想：利用Linux GNU make C 專案管理軟體工具實現資料結構棧(Stack)。實現Push，Pop，Delete,Search,Visit through,Clear功能。節點的資料設計具有一般性（使用void *da

資料庫工作筆記002---Linux下開啟,重啟,關閉mysql

linux下開啟、關閉、重啟mysql服務命令 一、 啟動 1、使用 service 啟動：service mysql start 2、使用 mysqld 指令碼啟動：/etc/inint.d/mysql start 3、使用 safe_mysqld 啟動：safe_m

TCP連線管理機制-確認應答，超時重傳，滑動視窗，擁塞控制，流量控制，延遲應答

TCP通過確認應答和超時重傳可以保證資料可靠傳輸 使用滑動視窗完成流量控制和擁塞控制 使用延遲應答來保證滑動視窗足夠大 接下來對這些機制進行詳細的介紹 確認應答（ACK）機制 TCP將每個位元組的資料都設定了序列號，每一個ACK都帶有對應的確認序列號，告訴傳送者

linux下MySQL重置密碼

除博文介紹的方法外，還可以使用如下方法： sudo mysqladmin -u root -h localhost -p password “newPwd” 引號中的內容是新密碼，這裡的引號也可以不加，但如果密碼中存在特殊字元，需要加上引號。