最近，做了一个有关socks5代理的项目，对于其中的bind和udp associate仔细研究了一下，把自己认为正确的记个笔记。
BIND的用法
BIND一般用于客户端与服务端建立连接之后，用于新建立服务端到客户端的连接，类似于FTP的PORT命令会用到（有可能记错了，但是肯定是有一个模式是由服务端主动连接客户端，PASV模式？）。
这个过程的标准过程是这样的：
- 客户端先通过connect建立一个到服务端的信令通道。
- 客户端再建立一个新的连接到socks5 server，通过bind命令建立一个数据通道。socks5 server建立一个tcp的监听端口，但是为了安全起见，bind的时候客户端还会传一个DST地址，只限于指定地址来临的连接；bind成功之后，socks5 server返回监听的地址与端口到客户端；
- 客户端通过信令通道（也可以使用其它任意的通道）把这个监听地址信息传给服务端；服务端通过正常的tcp connect操作连接socks5 server上的监听端口；连接建立之后，socks5 server再传送一次BIND成功的信息，这一次就有了真正的连接者（服务端）的连接信息了。
所以说BIND事件是有两次返回的，第一次是客户端BIND通过socks5 server建立监听端口成功之后；第二次是直接连接发生的时候。这段话写得有点绕，主要是在BIND的操作中，服务端与客户端其实倒了一个身份，变成服务端主动连接客户端了。
UDP associate
UDP用于建立一个UDP的跳转通道（依赖于TCP的socks5协议），过程如下：
- 客户端与socks5 server建立tcp的连接；
- 客户端发送udp associate请求，socks5 server分配一个udp的端口，并将此端口返回给客户端；同前面的BIND一样，客户端也可以限制使用此udp的使用范围（谁可以使用）；
- 客户端将自己要发送的UDP报文发送到到socks5 server，但是前面是有一个复用头的，它告诉socks5 server真正发送到哪里去；回头的报文也按照相同的格式进行封装。
- 对于转发的UDP报文，无论是成功与否，都不再有额外的通知报文。
- 这里的associated的udp通道与tcp通道，具有相同的生命周期。
