在上一篇部落格中已經說明了本專案的技術路線，本篇部落格就來具體說說。

一.利用虛擬化技術搭建雙機器雙網絡卡的測試環境

首先是在VMWARE裡面新增兩個ubuntu虛擬機器，這個網上資料很多，在此就不贅述。這兩個ubuntu虛擬機器可以視為是編譯機，我們主要是藉助他們來編譯核心和製作檔案系統。這兩個虛擬機器的網路配置需要都配置成橋接模式。所謂橋接模式，簡單地說，就是把傳送給虛擬網絡卡的資料直接傳送給物理網絡卡，相當於虛擬網絡卡直接連在物理網絡卡之上。

然後就需要在每個虛擬機器裡面，藉助QEMU再構建出一個linux環境。這個linux環境跑的是我們自己製作的核心映象和檔案系統。具體可以參考部落格：

http://www.cnblogs.com/senix/archive/2013/02/21/2921221.html

http://www.cnblogs.com/pengdonglin137/p/5023340.html

出於測試需要，每個QEMU的環境都需要配置兩個網絡卡，這兩個網絡卡對應的IP地址處於不同的網段，並且對應不同的MAC地址。最終搭建的測試環境如下：

如上圖所示，有兩個QEMU模擬節點N1，N2。

N1的網路配置情況：

eth0  192.168.100.119   52:54:00:12:34:12   負責傳送資料

eth1  192.168.50.119     12:14:00:12:34:90    負責接收資料

N2的網路配置情況：

eth0 192.168.100.120   52:54:00:12:34:68   負責接收資料

eth1 192.168.50.120    12:14:00:12:34:57   負責傳送資料

二. 閱讀和修改TCP/IP協議棧原始碼

核心程式碼的體量很大，從0開始閱讀的難度比較大。我選取的核心版本是linux 2.6.26, 因為這個版本的核心原始碼是跟《追蹤Linux TCP/IP程式碼執行--基於2.6核心》這本書相配套的 ，網上相關資料也多一些。下面具體分析一下我做了哪些改動。

1. 使用者態介面

 大家都知道TCP/IP協議棧提供了socket()、bind()、listen()這些使用者態介面，而核心層面的改動一般是以對使用者態透明為佳。所以我並沒有新增或者修改任何一個使用者態的介面，只是輕微改動了一下bind介面的物理含義。傳統的TCP/IP協議棧是C/S模式，client和server分工明確，一個server可以對應多個client。client需要預先配置server的地址，而server並不需要預先配置client的地址，client和server並不是對等的關係。但是雙向解耦TCP實際上針對P2P模式的環境，P2P的兩端是完全對等的，都需要知道對方的地址，這樣方可建立連線和完成資料通訊。

 假設主動發起連線的節點為N1，另一個節點為N2。N1、N2的網路配置情況如上面所述。對於N1而言，我們需要知道N2的哪個IP地址是負責接收資料的，所以我們直接沿用int connect(int sockfd, const struct sockaddr *serv_addr, socklen_t addrlen)介面，在serv_addr上面配置N2的接收資料IP 192.168.100.120即可。於N2而言，我們同樣需要知道N1的哪個IP地址負責接收資料，這裡我就沿用了int bind(int sockfd,struct sockaddr * my_addr,int addrlen)介面，在myaddr裡面儲存N1接收資料的IP 192.168.50.119。  當然，bind本來的含義不是這樣的，為了支援我新設的定義，在底層是需要進行修改的。bind本來的含義是保證server只會接收發送到myaddr的ip、埠的資料，不過大多數情況下myaddr.ip都是設定成IPADDR_ANY，表示server會接收所有傳送到myaddr.port的資料。我們這裡修改bind的含義，影響並不大。接下來就沿著TCP三步握手、資料傳送、四步揮手這樣的過程來一步步分析底層的改動。

     2.  client傳送SYN包，要求建立TCP連線

只需要N1的使用者態呼叫connect，並且將serv_addr配置成192,168.100.120，那麼核心就會自己構造SYN包傳送給192.168.100.120，這一步核心層面不需要進行修改。

     3.  server收到client傳送的SYN包，給client回送SYN+ACK包

server端收到SYN包之後，經過層層呼叫會進入tcp_v4_conn_request函式，下面來看看這個函式的部分程式碼：

__be32 saddr = ip_hdr(skb)->saddr;
__be32 daddr = ip_hdr(skb)->daddr;
...
ireq->loc_addr = daddr;
ireq->rmt_addr = saddr;
...
/* First, grab a route. */
if (!dst && (dst = inet_csk_route_req(sk, req)) == NULL)
	return -1;

skb = tcp_make_synack(sk, dst, req);

從上面擷取的這些程式碼可以看出，server端首先會解析SYN包，得到saddr和daddr。這裡saddr為192.168.100.119 daddr為192.168.100.120。然後給ireq結構體賦值，修改loc_addr、rmt_addr的值。然後，會進入

dst = inet_csk_route_req(sk, req)

這個函式很重要，是要查詢路由！查詢什麼路由呢，就是查詢從server到client的路由。也就是說，會查詢源地址(ireq->loc_addr)為192.168.100.120，目的地址（ireq->rmt_addr）為192.168.100.119的路由。這是傳統的TCP/IP協議棧所做的事情，自然是在同一個鏈路（兩個網絡卡之間）進行資料傳輸，但是跟我們的需求自然是相悖的。

那麼我們怎麼修改呢？回憶前面的bind系統呼叫，我們實際上是在sk->daddr儲存了N1的接收IP 192.168.50.119。 因此，我們是在進入inet_csk_route_req之前，修改req的loc_addr和rmt_addr：

ireq->loc_addr =  0; 
ireq->rmt_addr = inet->daddr;

然後進入inet_csk_route_req。查詢完路由表之後，得到路由表項rt，這時候rt->saddr就是192.168.50.120了。我們再修改ireq->loc_addr=rt->saddr，然後進入

 tcp_make_synack

這裡就會根據我們的需求製作SYN+ACK包了。這個SACK包，是由192.168.50.120發往192.168.50.119的。

  4. client收到SACK包，最後回送一個ACK包

這裡有一個問題。那就是client端如何識別出SACK包是自己需要的？在現有的TCP/IP協議棧程式碼中，client在傳送完SYN包之後，會根據hash[(saddr,daddr,sport,dport)]計算出一個值來標識對應的socket。那麼在收到SYN+ACK之後，client自然也會hash[(saddr,daddr,sport,dport)]來尋找對應的socket，但是此時的saddr、daddr已經變了，所以client是無法識別這個SACK包的！

那麼怎麼修改呢？這裡我採取了一個最簡單的辦法，我就只hash[sport,dport]，這樣SYN包和SACK包的hash值就一樣了，因此client就可以順利識別這個SACK包並且找到相對應的socket。client只要識別出了SACK包，接下來發送ACK包的過程也是ok的，並不需要進行修改。

  5. server收到ACK包，三步握手完成，建立一個新的socket fd

這一步在核心層面並不需要修改，到此雙向解耦TCP的三步握手完成。

  6. client呼叫send傳送資料

這一步自然也是不需要修改的。

  7. server收到資料，回覆ACK

這一步需要類似於步驟3做一下修改，具體的修改程式碼如下（tcp_rcv_established函式）：

if(inet_sk(sk)->taddr)
{		
	inet_sk(sk)->daddr = inet_sk(sk)->taddr;
	struct flowi fl = { .oif = sk->sk_bound_dev_if,
	.nl_u = { .ip4_u =
		{ .daddr = inet_sk(sk)->daddr,
		.saddr = 0,
		.tos = RT_CONN_FLAGS(sk) } },
		 .proto = sk->sk_protocol,
		.uli_u = { .ports =
		{ .sport = inet_sk(sk)->sport,
		 .dport = inet_sk(sk)->dport } } };

		/* If this fails, retransmit mechanism of transport layer will
		* keep trying until route appears or the connection times
		 * itself out.
		*/
		//security_sk_classify_flow(sk, &fl);
		if (ip_route_output_flow(sock_net(sk), &rt, &fl, sk, 0))
			goto discard;
		inet_sk(sk)->saddr = rt->rt_src;
		//inet_sk(sk)->saddr = 2016585920;

}
			
//inet_sk(sk)->rcv_addr = 0;
__tcp_ack_snd_check(sk, 0);
inet_sk(sk)->daddr = old_daddr;
inet_sk(sk)->saddr = old_saddr;

如上所述，在進入_tcp_ack_snd_check之前，需要先查詢路由表，然後修改sk->saddr即可。

8. server傳送資料

server主動傳送資料，同樣需要修改介面，修改函式tcp_write_xmit，修改程式碼同上。

9. client回送ACK

這個自然也不需要修改。

10.TCP四步揮手

也不需要修改程式碼的。

三.結果展示

我在使用者態寫了一個簡單的echo 應用程式，client從stdin獲取資料，然後傳送給server。server收到資料會馬上將其回送給client。wireshark的抓包結果如下：

從抓包結果上可以看出，TCP的三步握手、資料傳輸、四步揮手都是ok的。