Linux下超時重傳時間(RTO)的實現探究
最近出現了網路超時的問題要排查,大致按照如圖思路去排查
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” 引號中的內容是新密碼,這裡的引號也可以不加,但如果密碼中存在特殊字元,需要加上引號。