为什么Telnet可以用来检查TCP端口是否正常？
【问题背景】我们在日常的网络运维中，经常有这样的场景，实施了网络安全策略变更后，如何验证TCP端口已经可以正常经过防火墙访问了，我们经常采取的手段就是Telnet该服务器的TCP端口。那么为什么是Telnet，其他应用不行吗？为什么tetnet可以检查TCP端口正常打开？为什么是TCP端口，UDP端口不行吗？
【结论】先看结论，节约时间。其实除了Telnet，其他使用TCP端口的应用也是可以的，只不过Telnet比较容易看到结果，多数服务器支持，使用方便。Telnet之所以可以检查TCP端口，是因为Telnet使用了TCP协议。为什么UDP不行，因为Telnet使用的是TCP端口，UDP可以使用NetCat等应用检查。
【解】
一、TCP和UDP的区别，TCP三次握手
正常知识储备，哪哪都有，这里不再说了，上一个三次握手的图，好结合下面的内容看一下。
图片来自网络，侵删
二、TCP模块是如何处理包的
这里主要说一下服务器端的TCP模块是如何处理包的，网卡接收到数据包，一顿操作之后给到IP模块，IP模块一顿操作之后给到TCP模块。故事就从这里说起。我们假设现在接收到的是第一个TCP包，控制位SYN＝１，TCP模块会检查包的接收方端口号，并确认在该端口上有没有与接收方端口号相同的且正处于等待连接状态的套接字。嘿，这里就检查了端口是否开通了。如果不存在该套接字，则向客户端返回一个表示接收方端口不存在等待连接状态套接字的ICMP消息。
如果存在等待连接的套接字，则为这个套接字复制一个新的副本，并将发送方IP地址、端口号、序号初始值、窗口大小等必要参数写入这个套接字中，同时分配用于发送缓冲区和接收缓冲区的内存空间。然后生成代表接收确认的ACK号，用于从服务器向客户端发送的序号初始值，表示接收缓冲区剩余容量的窗口大小，并用这些信息生成TCP头部，委托IP模块发送给客户端。
这个包到达客户端之后，客户端会返回表示接收确认的ACK号，当这个ACK号返回服务器之后，连接就完成了。
这个过程，跟用什么应用是没关系的。
三、抓包分析
在虚拟机中创建一个TCP 2233端口，使用的是web应用，可通过http访问，如下图
在本地Telnet该端口，可以连接成功，用浏览器也能打开
用ssh是不行的
服务器端可以看到连接后的端口状态变化
因为使用的是http应用，所以浏览器能打开是很正常的一个事情，但浏览器不一定能打开其他程序的TCP端口，我们看到ssh是失败的，抓包看一下如果使用ssh，TCP是否建立成功
如上图所示，当我们使用ssh登录服务器时，TCP的三次握手是正常建立的，也就是说，检查TCP端口是否能正常建立连接，用其他应用也可以，不一定要Telnet。那么为什么还要用Telnet，可能只是比较方便，就好像我们刚才使用了ssh，其实也是可以看得出来有没有端口号的返回是有差异的，只不过没那么直观。
四、为什么是Telnet
我们使用Telnet的时候，比如启用的是web应用，Telnet也能进入可编辑端口。我们都知道，Telnet可以远程登录远端设备，默认使用TCP 23端口。这里就涉及Telnet的工作原理，Telnet并不是一个单纯的本地应用，登录使用Telnet服务时需要在服务器端启用Telnet服务器软件，并监控TCP 23端口。客户端使用Telnet登录远程服务器时，先建立TCP连接，TCP连接建立成功之后，Telnet客户端并没有检查所连TCP是否存在Telnet服务器应用，而是进入等待输入的状态，正常情况下应该输入用户名及口令或者命令发送给远程服务端，服务器Telnet应用将相应命令执行后返回回显信息。显然，我们只需要利用Telnet建立TCP连接的特性即可看出TCP连接是否建立成功。（下图是Telnet建立连接成功后进入等待输入的模式，看时间，什么都没做，就关闭了连接）
