windows下查看进程号与端口号的命令
TCP的三次握手
TCP 是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如 IP 地址、端口号等。TCP 可以看成是一种字节流，它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。TCP 提供了一种可靠、面向连接、字节流、传输层的服务，采用三次握手建立一个连接。采用四次挥手来关闭一个连接。TCP 服务模型在了解了建立连接、关闭连接的“三次握手和四次挥手”后，我们再来看下 TCP 相关的东西。一个 TCP 连接由一个 4 元组构成，分别是两个 IP 地址和两个端口号。一个 TCP 连接通常分为三个阶段：启动、数据传输、退出（关闭）。当 TCP 接收到另一端的数据时，它会发送一个确认，但这个确认不会立即发送，一般会延迟一会儿。ACK 是累积的，一个确认字节号 N 的 ACK 表示所有直到 N 的字节（不包括 N）已经成功被接收了。这样的好处是如果一个 ACK 丢失，很可能后续的 ACK 就足以确认前面的报文段了。一个完整的 TCP 连接是双向和对称的，数据可以在两个方向上平等地流动，给上层应用程序提供一种双工服务。一旦建立了一个连接，这个连接的一个方向上的每个 TCP 报文段都包含了相反方向上的报文段的一个 ACK。序列号的作用是使得一个 TCP 接收端可丢弃重复的报文段，记录以杂乱次序到达的报文段。因为 TCP 使用 IP 来传输报文段，而 IP 不提供重复消除或者保证次序正确的功能。另一方面，TCP 是一个字节流协议，绝不会以杂乱的次序给上层程序发送数据。因此 TCP 接收端会被迫先保持大序列号的数据不交给应用程序，直到缺失的小序列号的报文段被填。TCP 头部源端口和目的端口在 TCP 层确定双方进程，序列号表示的是报文段数据中的第一个字节号，ACK 表示确认号。该确认号的发送方期待接收的下一个序列号，即最后被成功接收的数据字节序列号加 1，这个字段只有在 ACK 位被启用的时候才有效。当新建一个连接时，从客户端发送到服务端的第一个报文段的 SYN 位被启用，这称为 SYN 报文段。这时序列号字段包含了在本次连接的这个方向上要使用的第一个序列号，即初始序列号 ISN，之后发送的数据是 ISN 加 1。因此 SYN 位字段会消耗一个序列号。这意味着使用重传进行可靠传输，而不消耗序列号的 ACK 则不是。头部长度（图中的数据偏移）以 32 位字为单位，也就是以 4bytes 为单位，它只有 4 位，最大为 15，因此头部最大长度为 60 字节，而其最小为 5，也就是头部最小为 20 字节（可变选项为空）。ACK —— 确认，使得确认号有效。RST —— 重置连接（经常看到的 reset by peer）就是此字段搞的鬼。SYN —— 用于初如化一个连接的序列号。FIN —— 该报文段的发送方已经结束向对方发送数据。当一个连接被建立或被终止时，交换的报文段只包含 TCP 头部，而没有数据。客户端和服务端通信前要进行连接，“三次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。每次都是接收到数据包的一方可以得到一些结论，发送的一方其实没有任何头绪。我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？而从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是由于第一次的“请求”触发，因此每次握手其实是可以得到额外的结论的。比如第三次握手时，服务端收到数据包，表明看服务端只能得到客户端的发送能力、服务端的接收能力是正常的。但是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了，并且作出了响应，从而得到额外的结论：客户端的接收、服务端的发送是正常的。
实验
配置命令：
[Huawei]dhcp enable
Info: The operation may take a few seconds. Please wait for a moment.done.
#创建hehe地址池并进入该视图
[Huawei]ip pool heheInfo: It’s successful to create an IP address pool.
#配置该地址池的地址范围
[Huawei-ip-pool-hehe]network 192.168.1.0 mask 255.255.255.0
#配置该地址池的网关
[Huawei-ip-pool-hehe]gateway-list 192.168.1.254
#配置该地址池的DNS服务器
[Huawei-ip-pool-hehe]dns-list 192.168.2.253
#退出地址池视图
[Huawei-ip-pool-hehe]q