企业官网建设流程全解析

你十有八九遇到过这类问题：SSH连服务器连不上、网页突然502、FTP登录成功但目录刷不出来。表面看是三个完全不同的软件故障，仔细一挖会发现，它们全都卡在了同一个地方——TCP连接。先说结论：SSH、HTTP、FTP虽然长相完全不一样，但它们全都建立在TCP之上，理解这一点，等于掌握了排查这类网络问题的总开关。这篇文章会把三层关系讲明白：TCP负责什么、HTTP/SSH/FTP各自在TCP上做了什么、以及你在真机环境里最常碰到的那些报错到底是什么意思。适合刚入门网络基础的开发、运维，以及所有被远程连接和文件传输折磨过的人。

1. TCP到底干了什么：三个协议共用的传输层地基

1.1 先分层：HTTP/SSH/FTP只是“信纸”，TCP是“挂号信服务”

要理解SSH、HTTP、FTP为什么都基于TCP，先得把网络分层这件事搞明白。网络上传输数据不是一个大文件直接丢过去，而是按层拆解。最常用的比喻是寄信：你写一封信（应用层，也就是HTTP、SSH、FTP干的事），把信交给邮局；邮局决定用挂号信还是平邮寄（传输层，TCP/UDP干的事）；信封上写地址交给分拣系统（网络层，IP干的事）；最后实际运送靠公路铁路（链路层）。

应用层协议负责“信的内容长什么样”：HTTP规定请求行、请求头、响应状态码的格式；SSH规定加密协商、认证、终端会话的格式；FTP规定用户名密码、文件列表、上传下载命令的格式。但它们都不管“这封信能不能可靠送到”，这件事TCP全包了。

我经常跟刚入门的朋友说一句话：你抓包看HTTP流量，看到的其实是TCP段里装着一块HTTP数据。TCP的作用是把字节流切成一个个段，加上序号、确认号，然后在不可靠的IP网络上，实现可靠的传输。所谓“基于TCP”，意思是这些应用层的报文，最终都要先交给TCP去封装，TCP再把整个数据交给IP去寻址。没有TCP这一层，你的HTTP请求发出去可能半路就丢了，SSH命令敲进去可能缺字节，FTP传个大文件更是会传出一堆乱码。

1.2 三次握手的本质：一个可靠的“开始通话”确认

TCP最常见的考点就是三次握手，但很多人背了流程却不理解为什么。我拆开来讲。建立连接前，客户端和服务端其实谁也不知道对方是否在线、收发能力是否正常。三次握手做的一件事就是：让双方都确认“你能收到我的消息，我也能收到你的消息”。

流程严格来说是这样的：

• 客户端发SYN包：seq=x，意思是“我要建立连接，我的初始序号是x”。
• 服务端回SYN+ACK包：seq=y，ack=x+1，意思是“收到你的请求，我的初始序号是y，下次我期待收到你序号为x+1的数据”。
• 客户端发ACK包：seq=x+1，ack=y+1，意思是“收到你的确认，下次我期待收到你序号为y+1的数据”。

为什么偏偏要三次而不是两次？因为网络是不可靠的，有可能客户端第一次发的SYN因为网络拥塞被卡了很久，客户端以为丢了就重发，结果两个SYN都到了。如果只握手两次，服务端收到第一个SYN就建立连接，等这个连接不用了，那个老的SYN又冒出来，服务端就会误以为这是新连接请求，白开一个资源。有了第三次握手，客户端发现这个老SYN对应的连接自己早就不要了，就不会回应ACK，服务端收不到第三次ACK，自然也不会建立连接。

实际排查时了解这个很有用。用tcpdump抓包看到只有SYN没有SYN+ACK，说明包发出去了但对方没回应，大概率是对方服务没起或者被防火墙拦截；看到SYN+ACK发出去了但客户端没有回ACK，多半是客户端这边有安全软件拦截，或者NAT表项异常。我经常用这个判断连接建立到哪一步断了，比瞎猜效率高得多。

1.3 可靠性不是白给的：确认、重传、滑动窗口

TCP和UDP最大的区别就是可靠性。但这可靠性不是玄学，是靠几个具体机制撑起来的。

确认与重传是最基础的。发送方发出一个段，会启动一个定时器，在规定时间内没收到对方的ACK就重发。Nagle算法会把小包合并发送减少小包数量，Delayed ACK让接收方攒几个包一起确认，这些细节在日常使用中你感知不到，但能直接影响交互式协议的手感。

滑动窗口则负责流量控制。TCP不是发一个包等一个确认，而是一次可以发一批，窗口大小决定了“没收到确认前最多还能发多少”。接收方会在ACK里带上自己的窗口大小，如果它处理不过来，窗口会变小，发太快甚至会变成0，告诉发送方“你先停下来”。SSH、HTTP在弱网环境下卡顿，很多时候不是应用层的问题，而是TCP窗口在动态调整，把发送速率压下来了。明白这一点，你就不会在弱网环境下一味去调应用超时时间，而是先看TCP重传率和窗口变化。

还有一个拥塞控制，这也是TCP被设计得“保守”的原因。TCP从慢启动开始，拥塞窗口翻倍增长，遇到丢包就减半甚至回归初始值。所以我一直建议做网络排查的人，先学会看TCP层的指标——重传率、乱序率、RTT——再看应用层指标，很多疑难杂症瞬间就有了答案。

2. HTTP与TCP：浏览器背后那条看不见的连接

2.1 一次网页请求在TCP层面到底发生了什么

你在浏览器输入一个网址回车，表面上只是页面刷出来了，背后发生了一串动作。先DNS解析出IP，然后TCP三次握手建立连接（从 tcpdump 能看到 SYN、SYN-ACK、ACK 三个包），再发送HTTP请求，服务端返回HTTP响应，如果是HTTP/1.0老协议，请求完还会立刻断开连接；HTTP/1.1之后默认保持连接，为的是让后续多个请求复用这条TCP隧道。

这里有个容易混淆的概念：HTTP本身是无状态的，每个请求是独立的，但它传输的载体TCP是面向连接的。上次提到的热词“http连接复用”就是这么来的。HTTP/1.1的Keep-Alive机制允许同一个TCP连接上连续发送多个HTTP请求，节省了反复握手的开销。HTTP/2更激进，直接在一条TCP连接上多路复用多个并发流，一个慢请求不会阻塞后面所有请求。

实际工作中，我发现很多人排查HTTP慢，上来就查数据库、查接口逻辑，其实先把TCP层看一遍更有效。比如RTT很高、有大量重传，那接口再快也没用，数据到不了浏览器。用 curl -v https://example.com 能看到连接建立耗时和TLS握手耗时，用 curl -w 还能把各阶段时间拆出来。这些是HTTP问题排查的第一手资料。

2.2 连接复用与502/503：TCP连接状态直接决定你看到的报错

HTTP报错里最常见的就是502和503，很多人误以为是应用挂了，其实根子在TCP连接状态。502 Bad Gateway是网关（Nginx、API网关、本地代理）向后端发起TCP连接时失败，或者建立后后端异常关闭；503一般对应服务过载或主动拒绝连接。

有个非常典型的场景，本地跑了一个代理服务监听127.0.0.1:1572，某个程序请求 http://127.0.0.1:1572 时报 “unexpected status 502 bad gateway: unknown error”。这个报错的关键在于“连接一个本地端口失败”。先确认端口有没有监听：Linux下用 ss -lntp | grep 1572，Windows下用 netstat -ano | findstr 1572。如果端口没监听，那是上游服务没起来；如果端口在监听但返回502，那可能是代理程序自己连接上游失败，或者它向后端发出的TCP连接被拒绝。

还有一种情况是后端服务处于半连接状态，比如数据库连接池爆了，进程还在accept，但已经不处理请求；或者服务端因为某些原因主动关闭了keep-alive连接，客户端还傻傻地复用，于是收到RST，浏览器里就表现为“连接被重置”或网关报502。排查这种问题的标准路径是：看网关日志里的upstream status，看后端服务日志，再用curl从网关本机请求后端地址，判断是TCP层不通还是应用层报错。每一层都有每一层的日志，别一上来就重启服务。

2.3 HTTPS到底改了什么：还是TCP，只是中间多了一层加密

很多人以为HTTPS是另一个协议，其实它的底层仍然是TCP。HTTPS在HTTP和TCP之间加了一层TLS/SSL。TCP仍然负责可靠传输数据，TLS只负责给数据加密、校验完整性、验证身份。所以你可以把HTTPS理解成“把信纸装进了一个带锁的保险信封，然后仍然用挂号信寄出”。

这个结构会导致一个常见的性能问题：建立HTTPS连接需要TCP三次握手（1次RTT）再加TLS握手（至少1次RTT，如果协商新密钥可能要2次RTT）。所以在线事务较多的场景，大家会把TLS会话缓存、会话票据（session ticket）开起来，减少TLS握手的开销。HTTP/2和HTTPS几乎锁死，因为HTTP/2的多路复用优势在TLS之上依然成立，而且主流浏览器都要求HTTP/2跑在TLS上。

排查HTTPS问题时，要区分TCP层和TLS层。比如 openssl s_client -connect example.com:443 能完整看到TCP连接、TLS握手证书链、协议版本。如果TCP能通但TLS握手失败，多半是证书问题、协议版本不匹配、或者中间设备（比如防火墙）干扰了TLS握手。我之前遇到过一台服务器应用本身没问题，但curl始终报证书错误，最后发现是系统时间差了几天，证书校验因为时间不在有效期内而失败。TCP没问题、TLS报错，这种“一层层剥洋葱”的思路，在排障时非常管用。

3. SSH与TCP：远程管理为什么必须走“可靠通道”

3.1 SSH和TCP的分工：握手只是入场券，后面还有加密和认证

SSH是Secure Shell的缩写，跑在TCP 22端口上。它的核心特征是：先通过TCP三次握手建立一条可靠通道，然后在这个通道里协商加密算法、交换密钥、完成认证，之后才允许你敲命令。TCP连接只是“入场券”，真正干活的加密和认证发生在TCP已经建立之后的应用层会话里。

为什么SSH一定要用TCP而不是UDP？因为SSH是一交互式终端协议，你敲下的每一个字符、服务器回显的每一帧输出，都不能丢。如果走UDP，网络一抖动就可能丢字符，终端命令回显不完整，你用起来会抓狂。TCP的确认、重传、按序到达机制，保证了终端数据的完整性和顺序性。顺带一提，很多人听过的Mosh（Mobile Shell）确实使用UDP，但它不是替代SSH认证的，它还是在SSH认证成功之后建立会话，用UDP来做本地回显和漫游，属于“SSH都建立好了之后再加一层优化”的方案，和SSH本身基于TCP并不冲突。

SSH连接的详细过程：TCP三次握手完成后，客户端和服务端交换版本字符串，然后进行密钥交换（常见算法curve25519-sha256、ecdh-sha2-nistp256），生成会话密钥，之后才是用户认证阶段——密码认证或公钥认证。这也是为什么你SSH连不上的时候，要分阶段排查：TCP层通不通、SSH服务有没有监听、密钥协商是否成功、认证是否通过。每一阶段失败的表现都不一样。

3.2 免密登录实操：群晖、Git、VSCode背后的密钥配置逻辑

热词里提到“群晖上配置好ssh密钥，我走免密登录”，这是SSH公钥认证的标准玩法。我把通用步骤整理出来，不管是群晖、Ubuntu还是其他Linux发行版都适用。

先在本地生成密钥对：

ssh-keygen -t ed25519 -C "你的备注"

一路回车就会在 ~/.ssh/ 下生成 id_ed25519（私钥）和 id_ed25519.pub（公钥）。公钥可以随便给别人，私钥绝对不要泄露。

然后把公钥放到服务器的 authorized_keys 文件里：

ssh-copy-id user@server_ip

如果没有 ssh-copy-id，就手动追加：

cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

注意权限非常关键。服务器端 ~/.ssh 目录要700，authorized_keys 文件要600，私钥本机也要600，否则客户端会拒绝使用。

之后 ssh user@server_ip 就直接免密登录。Git的SSH配置也是同一个逻辑：本地生成密钥，把公钥粘贴到GitHub/GitLab/Gitee后台，然后测试 ssh -T git@github.com，通了就可以用git协议推送代码。VSCode远程连接服务器时，把公钥放到目标机器的authorized_keys里，再在 ~/.ssh/config 里配置好Host别名、主机名、用户、私钥路径，编辑器里就能一键连接。

我踩过一个坑：公钥明明放上去了，服务器还是让你输密码。查一下SSH服务端日志，如果提示“Authentication refused: bad ownership or modes”，基本就是authorized_keys或家目录权限不对。另外一个冷门坑是SELinux开启了，会阻止sshd读取新写入的authorized_keys，需要用 restorecon -R -v ~/.ssh 恢复上下文。

3.3 Ubuntu SSH连不上怎么办：一套固定的排查路径

“Ubuntu SSH无法连接”也是高频问题，这里给一套固定排查顺序。

第一步，确认sshd服务在跑：

systemctl status sshd

没起来就 systemctl start sshd。第二步，确认22端口在监听：

ss -lntp | grep 22

第三步，本机测试回环：

ssh localhost

如果本机都连不上，问题在sshd配置或密钥权限；如果本机能连、外部不能连，基本是防火墙问题。Ubuntu默认可能没开ufw，但如果你之前启用过，记得放行22端口：

sudo ufw allow 22/tcp sudo ufw status

还有一种隐蔽情况：云服务器的安全组规则拦掉了22端口，但本机防火墙完全没问题。我建议先看安全组，再用 nc -vz server_ip 22 测试端口是否通，最后再判断应用层。

热词里有“网络攻击 ssh大量连接怎么办”，这个也不少见。如果 /var/log/auth.log 里全是同一个IP反复尝试登录，说明遭遇暴力破解。对策是：禁止密码登录只留公钥认证（把 /etc/ssh/sshd_config 里的 PasswordAuthentication 改成 no）、修改默认端口（虽然治标不治本）、安装fail2ban自动封禁频繁失败的IP。普通小服务器做到这三步，基本能挡住95%的扫描。

4. FTP与TCP：协议设计里最特殊的“双连接”

4.1 一个协议两个TCP连接：控制连接和数据连接怎么配合

FTP是文件传输协议的老前辈，但它里面藏着一个让很多人头疼的设计：一个FTP会话同时使用两个TCP连接。控制连接默认走21端口，负责传命令和响应，比如用户名、密码、LIST、RETR、STOR这些指令；数据连接负责传实际的文件内容或目录列表。

所谓主动模式（Active Mode）下，控制连接建立后，客户端用PORT命令告诉服务器自己开了哪个端口，服务器主动从20端口去连客户端的那个端口。问题在于，如果客户端在NAT后面，服务器根本连不进来。所以后来主流都改用被动模式（Passive Mode）：客户端发PASV命令，服务器返回一个随机端口，客户端主动去连这个端口。这样对NAT友好得多。

两种模式对比：

记住这句话：FTP控制连接永远由客户端发起，但数据连接的发起方向随模式变化。很多FTP传不了文件的问题，根子就在这里。

4.2 能登录却传不了文件：90%出在数据连接被拦截

最经典的现象就是“FTP可以登录，但没法传文件”：用户名密码正确，目录列表能出来，一旦上传下载就卡死或者报错。因为控制连接通了，能登录；但数据连接被拦了，传不了文件。

防火墙和NAT是最常见的元凶。看到FTP的21端口开放就以为万事大吉，忽略了被动模式还需要开放一批高位端口（比如阿里云、腾讯云安全组默认不会放行1024以上端口）。在服务器端配置vsftpd时，固定被动端口范围是个好习惯：

pasv_enable=YES pasv_min_port=30000 pasv_max_port=31000

然后把防火墙和安全组的30000-31000也一起放行。如果是主动模式失败，则要让服务器能主动连客户端，但客户端在NAT后就很难支持，我自己的建议是：能不用主动模式就不用主动模式，直接切被动模式。

另外一个隐藏坑：服务器返回给客户端的PASV地址是内网地址，导致客户端拿到内网IP去连。这种情况需要在vsftpd里配置 pasv_address，让服务器返回自己的公网IP，例如：

pasv_address=你的公网IP

如果服务器本身在NAT后面做端口映射，这一步必须做，否则客户端永远连不上数据端口。热词里的“ftp可以登录无法传文件”基本都能归类到这几类原因。

4.3 两台电脑通过FTP传文件：完整实操和选型建议

热词里有“两台电脑怎么通过ftp传文件”，我直接给你一套最小可用方案。假设局域网内A电脑要传文件给B电脑，把A当FTP服务器，B当客户端。

服务端最简单的方式是Windows自带IIS的FTP功能，或者装FileZilla Server。我推荐FileZilla Server，轻量又好配。安装后设置监听端口21，创建用户并指定主目录，Windows防火墙放行21端口和被动模式端口范围。客户端装FileZilla Client，填A的IP、用户名、密码，连接后就可以双向传输。

不过这里我要多说一句：如果只是为了临时传文件，FTP未必是最优解。同一局域网用网线或WiFi共享、用python起个HTTP服务（python3 -m http.server 8000）甚至用scp都更简单。FTP在这类场景里的优势是断点续传和权限管理成熟，但在公网上明文传输密码和数据是个大问题，热词里也有“ftp 安全登录 ssh”和“ftp 0x800ffff”这样的衍生问题。我个人的建议是：局域网内部传文件，FTP够用；跨公网传敏感数据，选SFTP（走SSH，22端口，加密）或FTPS（FTP over TLS）。

顺带提一句FileZilla客户端报“不支持的服务器”“不支持ftp over tls”：这说明服务器端只提供普通FTP，而客户端默认要求强制TLS加密。如果确认是自己搭建的测试环境，可以在站点管理器里把加密方式改成“仅使用普通FTP”；但公网上传任何重要文件我都不会这么做。

4.4 SFTP不是FTP：别再混淆这两兄弟

很多人以为SFTP是FTP的安全版本，这是个流传很久的误解。SFTP的全称是SSH File Transfer Protocol，它建立在SSH协议之上，复用SSH的22端口和加密通道，而不是标准FTP的21端口加TLS。换句话说，SFTP属于SSH协议族，它和FTP只是名字长得像，机制上完全不同。

这也是为什么SFTP在NAT环境下通常更好用：它和SSH一样只用一个TCP连接，不像FTP那样需要动态开第二个数据连接。也因为这个原因，我遇到“FTP无法穿透NAT”的问题时，往往直接建议用SFTP替代。如果你只是想在两台电脑之间安全传文件，而恰好已经在跑SSH服务，直接用SFTP就行，FileZilla客户端原生支持，几乎是零成本迁移。

5. TCP连接的“善后工作”：拆分、挥手与端口占用的坑

5.1 四次挥手和TIME_WAIT：为什么端口会被“粘住”

TCP连接建立要三次握手，断开却要四次挥手，原因在于TCP支持半关闭状态。第一次挥手：主动关闭方发FIN，表示“我的数据发完了”；被动方回ACK，表示“收到你的FIN”；如果被动方还有数据没发完，它会继续发；等数据发完了，被动方再发FIN，表示“我这边也结束了”；最后主动方回ACK确认。所以被动方的ACK和FIN往往不能合并成一次，这就是四次而不是三次的原因。

四次挥手带来一个实际影响：主动关闭方会进入TIME_WAIT状态，要等2MSL（报文最大生存时间的两倍，Linux上大概60秒）才会释放连接。这个设计的初衷是怕最后一个ACK丢了，对方没收到FIN的确认会重发FIN；同时也为了等网络中的旧报文彻底消失，避免它干扰新连接。

TIME_WAIT本身是正常设计，但在高并发短连接场景下，大量连接处于TIME_WAIT，会导致“端口被占住”的感觉——你明明没看到程序还在跑，但端口就是起不来。这就是热词里那个报错的来源：error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket addr（Linux上对应“Address already in use”）。程序崩溃重启时，端口还在TIME_WAIT或端口没被释放，于是边界错误提示“该套接字地址只能使用一次”。

解决方式有几种：改监听端口、等60秒、或者在程序里设置SO_REUSEADDR。对于服务端监听端口，SO_REUSEADDR允许重用处于TIME_WAIT的连接，这是很多网络程序默认会做的设置。但对运维来说，看到大量TIME_WAIT不代表有问题，只要数量没有持续增长到把端口耗尽，就不用过度紧张。排查时用 ss -s 看当前连接状态分布，一眼就知道TIME_WAIT多不多。

5.2 端口占用与超时：两个高频报错的现场排查

端口占用类报错有一个统一排查路径。Windows下：

netstat -ano | findstr 11434 tasklist | findstr PID

Linux下：

ss -lntp | grep 11434 lsof -i:11434

找到占用进程后，要么改配置换端口，要么停掉旧进程。注意还有一种情况是服务实际上已经退出了，但端口还处于TIME_WAIT，如果是监听端口会自动释放，如果是操作系统保留的高位端口没释放完，等一下或用 sysctl 调整 net.ipv4.tcp_tw_reuse（客户端连接可复用TIME_WAIT）与 net.ipv4.tcp_tw_recycle（老版本内核不建议开启）。

“TCP connect超时”也是高频问题。connect超时和连接拒绝是两回事：连接拒绝是对方回了RST，报错很快；超时是SYN发出去后一直没人应答，防火墙把包悄悄丢弃是常见原因。排查思路是分层测试：先 ping 测通不通，不通就是网络层问题；通的话再 telnet IP 端口，测TCP端口放没放。如果 ping 通但 telnet 端口超时，极大可能是防火墙拦了目标端口，而不是服务本身的问题。这类经验对排查SSH、HTTP、FTP的问题都通用，因为它们的底层全是TCP。

6. 一张速查表与我的排障心得

6.1 SSH/HTTP/FTP常见问题速查表

我把文章里涉及的问题整理成一张速查表，方便你遇到具体报错时直接对号入座。

这张表我建议你保存在手边，遇到问题先对位再动手。很多时候不是不会排查，而是排查顺序乱，东看一眼西看一眼，反而把问题搞复杂。

6.2 学会抓包，比什么教程都管用

接入了TCP这个层面之后，我想认真建议你去学抓包。理解“SSH、HTTP、FTP基于TCP”这件事，只看文字很难有体感，但抓到一次包就全通了。最常用的抓包工具是tcpdump和Wireshark，tcpdump适合在服务器上快速验证，Wireshark适合图形化分析。

看一次完整的三次握手，可以这样：

tcpdump -nn -i any tcp port 22

然后另开一个终端执行 ssh user@server。你能看到三个包：SYN、SYN-ACK、ACK。再看一次HTTP请求，把端口换成80或443，你能看到TCP握手之后紧跟着HTTP GET请求，HTTP报文被TCP段完整包在里面。看FTP则更明显：控制连接上能看到USER、PASS、LIST这些命令，数据连接打开时会另有一个TCP连接在这个端口上建立。

判断某个问题出在TCP层还是应用层，我有个习惯性的二分法：抓包里能看到TCP握手成功，说明基础通道没问题，再看应用层协议交互；握手都没成功，就别去看应用配置，先把网络层和防火墙查明白。很多难缠的问题，都是这两层混在一起说的，最后用抓包把责任划分清楚，问题自然就清晰了。

6.3 从“协议三兄弟”延伸出去：更多基于TCP的常见场景

理解了SSH、HTTP、FTP基于TCP，你会发现自己其实掌握了一个通用框架。因为基于TCP的协议远不止这三个，热词里还有不少例子。比如modbus tcp，是工业自动化设备通信常用的协议，它同样是把Modbus报文封装在TCP里，靠TCP的可靠性保证指令一定要送达；又比如嵌入式场景里的ESP01S模块，很多教程让你“用TCP连接到服务器”，本质就是先用AT指令建立TCP连接，再在上面跑MQTT或自定义协议；再比如Ubuntu下用socat做UDP转TCP，是因为有些应用只接受TCP连接，但设备端只发UDP，需要在中间做一个协议转换。

从TCP的视角看这些场景，你会发现它们共享同一个底层机制：连接建立、可靠传输、连接断开。区别只在于应用层把字节流解释成什么格式。这也是我写这篇文章想传达的核心：把TCP这块地基搞明白，你就不会再被各种看似无关的报错搞得晕头转向。每一条错误信息背后，都是一个TCP连接在某个阶段出了问题。

最后分享一个我自己的习惯：遇到任何网络协议相关的疑难杂症，第一件事永远是先抓包，第二件事是看TCP连接状态，第三才是查应用日志。按这个顺序走，绝大多数问题都能在半小时内定位。如果你还没有抓包习惯，可以找个周末，自己架一台虚拟机跑一个HTTP服务、一个SSH服务、一个FTP服务，然后分别抓包看看三种协议在TCP之上的不同长相。抓过一遍之后再遇到生产问题，你心里会踏实很多。