[QT] 使用QT設定 TCP/IP KeepAlive

在TCP/IP的機制下所建立的連線，如果Server/Client雙方都沒有要求執行結束的 Four-way handshake，則在TCP/IP機制下，雙方會認為對方一直連線中，直到Timeout结束後才會斷線。通常Timeout時間依據不同的作業系統而有些差異，但時間單位都是小時等級的，故就會發生如對方機器電源已斷電，但程式還是一直保持在E「STABLISHED」的狀態。

如果要解決這個問題，就可以使用TCP/IP 的KeepAlive機制，顧名思義，就是雙方定時回報還活著。範例如下，

QTcpSocket *_socket = new QTcpSocket(this);
if ( _socket != NULL ) {
    _socket->connectToHost(_address, _port);
    if ( _socket->waitForConnected(1000)) {
        int fd = _socket->socketDescriptor(); //一定要連線成功才可取得 descriptor
        int enableKeepAlive = 1;
        setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &enableKeepAlive, sizeof(enableKeepAlive));
        int maxIdle = 10;/* seconds */
        setsockopt(fd, SOL_TCP, TCP_KEEPIDLE, &maxIdle, sizeof(maxIdle));
        int count = 3;//send up to 3 keepalive packets out, then disconnect if no response
        setsockopt(fd, SOL_TCP, TCP_KEEPCNT, &count, sizeof(count));
        int interval = 2;//send a keepalive packet out every 2 seconds (after the 5 second idle period)
        setsockopt(fd, SOL_TCP, TCP_KEEPINTVL, &interval, sizeof(interval));
    }
}

而Linux的系统預設值如下，（注意：修改該參數則會影響到所以的Socket設定）

#cat /proc/sys/net/ipv4/tcp_keepalive_time 7200
#cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75
#cat /proc/sys/net/ipv4/tcp_keepalive_probes 9

Reference : 
[1] QTcpSocket狀態總是連接，甚至連接到乙太網

[Linux] 發生大量的 TIME_WAIT

在做Network Monitor時，觀察netstat -luntpa時，發現了大量的Socket正處於TIME_WAIT狀態。這是因為當Client發出close()時，TCP Stack並不會立即結束，而是會先處於在TIME_WAIT的狀態，直到時間超過MSL*2之後，才會正式Release這個資源[1]。這樣的設計是TCP/IP為了保護還沒處理完的事，所以提供這樣的保護機制。但如果短時間內有大量的Request時，這時可能會將Tcp的資源給吃光。

Linux Kernel支援了兩個設定來解決這個問題

• tcp_tw_recycle ：啟動縮短TIME_WAIT的時間（注意 ： 使用該參數在NAT環境下可能會發生問題。）
  
  echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
• tcp_tw_reuse： reuse在TIME_WAIT下的資源
  
  echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse

Reference :
[1] TCP 筆記
[2] 不要启用 net.ipv4.tcp_tw_recycle

[Network] Tcp 筆記

1.  建立階段

2. 關閉階段

3. 狀態圖

圖片取至 ： https://upload.wikimedia.org/wikipedia/commons/f/f6/Tcp_state_diagram_fixed_new.svg

Reference :
[1] TCP Connection Establishment Process: The "Three-Way Handshake"
[2] Transmission_Control_Protocol

[3] Web 服务器 TCP TIME_WAIT连接

[Network] Routing Table其實不只一個

    最近設計的一套系統，有兩張網卡A、B。而由於使用者的環境因素導致我的Routing Rule不論怎麼設定，封包可能從網卡A進來，但卻從網卡B進到另一個網段，而導致封包回不來之窘境。


這個問題卡好久啊，總算找到解法了。概念其實很簡單，從A網卡進來的封包就走A網卡的Routing Table，而從B網卡進來的封包就走B網卡的Routing Table。而實作方式使用 iproute2。(Ubuntu Linux預設就有這個套件)

以下範例則是參考[1]。假設兩線路ADSL和Cable，希望從ADSL進來的封包就從ADSL的路徑回去，反之一樣，從Cable進來的封包則從Cable回去。

網路環境設定如下：
eth1 192.168.100.50 Gateway 192.168.100.254 --> ADSL
eth2 192.168.200.100 Gateway 192.168.200.254 --> CABLE

設定方式：

1. 新增 Table
   #vim /etc/iproute2/rt_tables
   
   1    ADSL
   2    Cable


2. 各至設定routing rule
   
   // 設定ADSL Routing Table
   #ip route add 192.168.100.0/24 dev eth1 src 192.168.100.50 table ADSL
   #ip route add default via 192.168.100.254 table ADSL
   
   // 設定CABLE Routing Table
   #ip route add 192.168.100.0/24 dev eth1 src 192.168.100.50 table CABLE
   #ip route add default via 192.168.100.254 table CABLE
   
   // 指定從哪張網卡來的封包走哪個Routing Table
   #ip rule add from 192.168.100.50 table ADSL
   #ip rule add from 192.168.200.100 table CABLE
   
   
   // Delete routing rule
   #ip rule del from 192.168.100.50 table ADSL
   #ip rule del from 192.168.200.100 table CABLE
   
   // Show routing by table
   #ip rule show table ADSL
   #ip rule show table CABLE

Reference :
[1] LINUX上的雙網路共享

[Network] 如何利用Switch做跨網段通訊

圖一：網路架構圖

我利用mininet模擬一台最基本的switch（如圖一所示），想觀察當封包要跨網段時，Switch的運作模式。首先，我從PC1發出ICMP給PC2(PC1 ping PC2-192.168.2.2)，一直收不到PC1的ICMP。

而透過Routing Table猜測，假設PC1並沒有設定一條GW告訴OS從哪個網卡出去，也就是說ICMP連從被PC1發出去的機會都沒有。

因此我加入一條Static Routing Rule給PC1 (192.168.2.0/24 --> PC1-eth0)。然後再觀察發現ICMP Request一樣沒被發出來，只有ARP不斷詢問192.168.2.2的MAC，但PC2竟然沒有回應ARP Reply。

從結果猜測，當ARP進入PC2 後，當進入到Routing Table時發現，並沒有192.168.1.0/24的相對應Rule，因此又被Drop。最後我又在PC2加入一條Static Routing Rule(192.168.1.0/24 --> PC2-eth0)後，兩邊即可通訊。

從上述整理，一般封包被送出，會先經過Routing Table確認該封包要從哪個Interface出去，並且是否符合Rule。通過Routing Table後再到ARP Table確認Dst MAC與Dst IP之對應，若ARP Table已有對應資料，則改掉封包的Dst MAC欄位後送出。而若沒有對應資料則會發送ARP Request去取得對應Dst MAC。

封包送出流程如下： Packet --> Routing Table --> ARP Table 

因此，若要解決這個問題的方法：

1.  分別對PC1和PC2加入兩條Static Routing Rule
2. 利用一台Router完成。
   
   PC1 設定gw:192.168.1.1，PC2設定gw:192.168.2.1。此時將PC1 ping PC2時，因為Routing Rule都沒有match，則封包送到Default gw(192.168.1.1)，Router收到該封包後，發現Dst ip 是PC2，則執行Forwarding到PC2。而封包回來時，PC2一樣發現沒有match到任何一個Routing Rule，因此一樣送到Default gw(192.168.2.1)，此時Router又發現Dst IP是PC1，又將封包Forwarding回PC1。

[Network] 發生大量 ARP Request

 一大早，就聽同學說，我的主機一直發出ARP攻擊，癱瘓掉別的實驗室的網路。

啥!!!原來我的電腦這麼強大阿~哈，....不對，應該先趕快複習一下ARP理論，並且看一下到底
發生了甚麼事。


其實ARP 的原理很簡單，主要就是用來查詢相對應的IP和MAC，在Internet之間雖然都是使用IP Address來進行溝通，但是底層的真實資料交換，其實還是透過MAC來達成， 所以才會有一套IP與MAC之間的轉換協定。而有ARP，當然就會有RARP，他們兩個之間的關係如下表示 :

    IP Address       == ARP    ==>    MAC Address
    Mac Address    == RARP ==>    IP Address

接下來，利用Wireshark or Packetyzer 來查看ARP的封包格式

• Hardware Type : Ethernet = 1

• Protocol Type = 使用IP做為定址模式 = 0800

• Opcode request =  1(ARP Reqeust)、2(ARP Reply)、3(RARP Request)和4(RARP Reply)

大致上，了解ARP的欄位定義後，接來來開始看真實的目前狀況，一樣利用Wireshark擷取目前網路狀態，我收集了大概1500筆的ARP封包，但可惜的是，沒有發現同學所說的，大量ARP Request的問題，加上沒人來抗議，所以就....先這樣瞜XD。

不過這過程中，有幾個問題待我想去查的

 

Q1. 到底一秒鐘發出多少個ARP Request才算是不正常現象

Q2. 不知道為什麼，有時候主機會去詢問一些似乎不存在的IP Address

Q3. 到底是由哪知程式所發出的Request

Reference

[1] 網路教學-ARP 協定

[2] arp偽裝攻擊網管人員查找解毒

[3] ARP欺騙 

[4] 實現ARP 攻擊

[Network] ICMP Redirect

ICMP Rediect的主要功用是告訴發送Request的主機，有更好的Path可以走。

Scenario :
如果有一台Host嘗試送資料給R1，而R1接收到資料後又立即送至R2，這個過程中，R1發現Host與R2其實是在相同的網段(或者有更短路徑)，不需要透過R1 forwarding 給R2，此時R1將會發出 Redirect Message packet 給Host，告訴Host 有更好的routing可用(直接R2溝通)。


Reference:
[1] Internet Control Message Protocol
[2] 主題: icmp redirect一問
[3] Icmp redirect起什么作用的呢?