数据链路层在物理层的基础上通过差错的检测、控制来提升传输质量，并可在局域网内使数据报文跨主机可达。这些功能是通过在报文的前后添加Frame头尾部实现的，如上图所示。每个局域网由于技术特性，都会设置报文的最大长度MTU（Maximum Transmission Unit），用netstat -i(linux)命令可以查看MTU的大小：

而IP网络层的目标是确保报文可以跨广域网到达目的主机。由于广域网由许多不同的局域网，而每个局域网的MTU不同，当网络设备的IP层发现待发送的数据字节数超过MTU时，将会把数据拆成多个小于MTU的数据块各自组成新的IP报文发送出去，而接收主机则根据IP报头中的Flags和Fragment Offset这两个字段将接收到的无序的多个IP报文，组合成一段有序的初始发送数据。IP报头的格式如下图所示：

图2 IP报文头部 IP协议头（本文只谈IPv4）里最关键的是Source IP Address发送方的源地址、Destination IP Address目标方的目的地址。这两个地址保证一个报文可以由一台windows主机到达一台linux主机，但并不能决定一个chrome浏览的GET请求可以到达linux上的nginx。 4、传输层主要包括TCP协议和UDP协议。这一层最主要的任务是保证端口可达，因为端口可以归属到某个进程，当chrome的GET请求根据IP层的destination IP到达linux主机时，linux操作系统根据传输层头部的destination port找到了正在listen或者recvfrom的nginx进程。所以传输层无论什么协议其头部都必须有源端口和目的端口。例如下图的UDP头部：

图3 UDP的头部
TCP的报文头比UDP复杂许多，因为TCP除了实现端口可达外，它还提供了可靠的数据链路，包括流控、有序重组、多路复用等高级功能。由于上文提到的IP层报文拆分与重组是在IP层实现的，而IP层是不可靠的所有数组效率低下，所以TCP层还定义了MSS（Maximum Segment Size）最大报文长度，这个MSS肯定小于链路中所有网络的MTU，因此TCP优先在自己这一层拆成小报文避免的IP层的分包。而UDP协议报文头部太简单了，无法提供这样的功能，所以基于UDP协议开发的程序需要开发人员自行把握不要把过大的数据一次发送。

对报文有所了解后，我们再来看看UDP协议的应用场景。相比TCP而言UDP报文头不过8个字节，所以UDP协议的最大好处是传输成本低（包括协议栈的处理），也没有TCP的拥塞、滑动窗口等导致数据延迟发送、接收的机制。但UDP报文不能保证一定送达到目的主机的目的端口，它没有重传机制。所以，应用UDP协议的程序一定是可以容忍报文丢失、不接受报文重传的。如果某个程序在UDP之上包装的应用层协议支持了重传、乱序重组、多路复用等特性，那么他肯定是选错传输层协议了，这些功能TCP都有，而且TCP还有更多的功能以保证网络通讯质量。因此，通常实时声音、视频的传输使用UDP协议是非常合适的，我可以容忍正在看的视频少了几帧图像，但不能容忍突然几分钟前的几帧图像突然插进来：-）

有其他办法么？有！如果客户端使用的源端口，同样用于接收服务器发送的响应，那么以上的问题就不存在了。像TCP协议就是如此，其connect方的随机源端口将一直用于连接上的数据传送，直到连接关闭。 这个方案对客户端有以下要求：不要使用sendto这样的方法，几乎任何语言对UDP协议都提供有这样的方法封装。应当先用connect方法获取到socket，再调用send方法把请求发出去。这样做的原因是既可以在内核中保存有5元组（源ip、源port、目的ip、目的端口、UDP协议），以使得该源端口仅接收目的ip和端口发来的UDP报文，又可以反复使用send方法时比sendto每次都上传递目的ip和目的port两个参数。

对服务器端有以下要求：不要使用recvfrom这样的方法，因为该方法无法获取到客户端的发送源ip和源port，这样就无法向客户端发送响应了。应当使用recvmsg方法（有些编程语言例如python2就没有该方法，但python3有）去接收请求，把获取到的对端ip和port保存下来，而发送响应时可以仍然使用sendto方法。   接下来我们谈谈nginx如何做udp协议的反向代理。

Nginx的stream系列模块核心就是在传输层上做反向代理，虽然TCP协议的应用场景更多，但UDP协议在Nginx的角度看来也与TCP协议大同小异，比如：nginx向upstream转发请求时仍然是通过connect方法得到的fd句柄，接收upstream的响应时也是通过fd调用recv方法获取消息；nginx接收客户端的消息时则是通过上文提到过的recvmsg方法，同时把获取到的客户端源ip和源port保存下来。我们先看下recvmsg方法的定义：

1

ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

相对于recvfrom方法，多了一个msghdr结构体，如下所示：

1
2
3
4
5
6
7
8
9

struct msghdr {    
    void         *msg_name;       /* optional address */    
    socklen_t     msg_namelen;    /* size of address */    
    struct iovec *msg_iov;        /* scatter/gather array */    
    size_t        msg_iovlen;     /* # elements in msg_iov */    
    void         *msg_control;    /* ancillary data, see below */    
    size_t        msg_controllen; /* ancillary data buffer len */    
    int           msg_flags;      /* flags on received message */
};

其中msg_name就是对端的源IP和源端口（指向sockaddr结构体）。以上是C库的定义，其他高级语言类似方法会更简单，例如python里的同名方法是这么定义的：

1

(data, ancdata, msg_flags, address) = socket.recvmsg(bufsize[, ancbufsize[, flags]])

其中返回元组的第4个元素就是对端的ip和port。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Load balance UDP-based DNS traffic across two servers
stream {    
    upstream dns_upstreams {        
        server 192.168.136.130:53;        
        server 192.168.136.131:53;    
    }     
    server {        
        listen 53 udp;        
        proxy_pass dns_upstreams;        
        proxy_timeout 1s;        
        proxy_responses 1;        
        error_log logs/dns.log;    
    }
}

在listen配置中的udp选项告诉nginx这是udp反向代理。而proxy_timeout和proxy_responses则是维持住udp会话机制的主要参数。 UDP协议自身并没有会话保持机制，nginx于是定义了一个非常简单的维持机制：客户端每发出一个UDP报文，通常期待接收回一个报文响应，当然也有可能不响应或者需要多个报文响应一个请求，此时proxy_responses可配为其他值。而proxy_timeout则规定了在最长的等待时间内没有响应则断开会话。

1
2
3
4
5
6
7

server {    
     listen 53 udp;
     proxy_responses 1;
     proxy_timeout 1s;
     proxy_bind $remote_addr transparent;     
     proxy_pass dns_upstreams;
}

1
2

# route del default gw 原网关ip
# route add default gw nginx的ip

1
2
3

# ip rule add fwmark 1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100 
# iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff

这套方案其实对TCP也是适用的。

1
2
3
4
5

server {
    listen 53 udp; proxy_responses 0;
    proxy_bind $remote_addr:$remote_port transparent;
     proxy_pass dns_upstreams;
}

2、与第一种方案相同，修改upstream的默认网关为nginx所在机器（任何一台拥有公网的机器都行）。 3、在nginx的主机上修改iptables，使得nginx可以转发upstream发回的响应，同时把源ip和端口由upstream的改为nginx的。例如：

1
2
3
4
5

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 action nat egress 172.16.0.12 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 action nat egress 172.16.0.13 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.14 match ip sport 53 action nat egress 172.16.0.14 192.168.99.10