我有一个设备的端口80已打开，我想知道背后是什么：
~ # curl -v http://192.168.10.253 root@srv
* Rebuilt URL to: http://192.168.10.253/
* Trying 192.168.10.253...
* TCP_NODELAY set
* Connected to 192.168.10.253 (192.168.10.253) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.10.253
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 192.168.10.253 left intact
curl: (52) Empty reply from server
为了更好地理解交换，我查看了数据包：
~ # tcpdump -vvv -nn host 192.168.10.253 and port 80 root@srv
tcpdump: listening on int0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:02:55.353246 IP (tos 0x0, ttl 64, id 9407, offset 0, flags [DF], proto TCP (6), length 60)
192.168.10.2.43894 > 192.168.10.253.80: Flags [S], cksum 0x967e (incorrect -> 0x0967), seq 2730220431, win 64240, options [mss 1460,sackOK,TS val 1779439926 ecr 0,nop,wscale 7], length 0
12:02:55.355251 IP (tos 0x0, ttl 255, id 1565, offset 0, flags [none], proto TCP (6), length 48)
192.168.10.253.80 > 192.168.10.2.43894: Flags [S.], cksum 0xdbda (correct), seq 100303, ack 2730220432, win 24576, options [mss 1460,nop,wscale 1], length 0
12:02:55.355270 IP (tos 0x0, ttl 64, id 9408, offset 0, flags [DF], proto TCP (6), length 40)
192.168.10.2.43894 > 192.168.10.253.80: Flags [.], cksum 0x966a (incorrect -> 0x65aa), seq 1, ack 1, win 502, length 0
12:02:55.355326 IP (tos 0x0, ttl 64, id 9409, offset 0, flags [DF], proto TCP (6), length 118)
192.168.10.2.43894 > 192.168.10.253.80: Flags [P.], cksum 0x96b8 (incorrect -> 0xeaeb), seq 1:79, ack 1, win 502, length 78: HTTP, length: 78
GET / HTTP/1.1
Host: 192.168.10.253
User-Agent: curl/7.58.0
Accept: */*
12:02:55.358822 IP (tos 0x0, ttl 255, id 1566, offset 0, flags [none], proto TCP (6), length 40)
192.168.10.253.80 > 192.168.10.2.43894: Flags [F.], cksum 0x3778 (correct), seq 1, ack 79, win 12249, length 0
12:02:55.358982 IP (tos 0x0, ttl 64, id 9410, offset 0, flags [DF], proto TCP (6), length 40)
192.168.10.2.43894 > 192.168.10.253.80: Flags [F.], cksum 0x966a (incorrect -> 0x655a), seq 79, ack 2, win 502, length 0
12:02:55.362046 IP (tos 0x0, ttl 255, id 1567, offset 0, flags [none], proto TCP (6), length 40)
192.168.10.253.80 > 192.168.10.2.43894: Flags [.], cksum 0x3778 (correct), seq 2, ack 80, win 12248, length 0
开始是握手，然后192.168.10.2发送 HTTP 负载。答案是上面的最后几行
12:02:55.358822 IP (tos 0x0, ttl 255, id 1566, offset 0, flags [none], proto TCP (6), length 40)
192.168.10.253.80 > 192.168.10.2.43894: Flags [F.], cksum 0x3778 (correct), seq 1, ack 79, win 12249, length 0
12:02:55.358982 IP (tos 0x0, ttl 64, id 9410, offset 0, flags [DF], proto TCP (6), length 40)
192.168.10.2.43894 > 192.168.10.253.80: Flags [F.], cksum 0x966a (incorrect -> 0x655a), seq 79, ack 2, win 502, length 0
12:02:55.362046 IP (tos 0x0, ttl 255, id 1567, offset 0, flags [none], proto TCP (6), length 40)
192.168.10.253.80 > 192.168.10.2.43894: Flags [.], cksum 0x3778 (correct), seq 2, ack 80, win 12248, length 0
这到底是什么FIN意思？这是商榷来自设备的答案，还是来自 TCP/IP 堆栈的通用答案，因为在交换过程中“出现了问题”？
答案1
它可能同时是其中一种，或者甚至两种情况都存在。
通常FIN 表示由应用程序发起的正常连接结束，即 HTTP 服务器进程故意在 TCP 套接字上使用 close() 或 shutdown()。就传输层而言，没有出现任何问题，即使 cURL 将此识别为应用层的问题。
相同的 FIN能当进程崩溃并且操作系统代表其关闭剩余连接时，也会发送该消息。您无法区分这两种情况，因为服务器的 TCP 也不知道其中的区别。
请记住，TCP 不处理请求和回复。它只提供平坦、连续的数据流，应用程序可以为其提供任何结构。即使应用程序出现故障，这些细节通常对 TCP 是不可见的 - 例如，崩溃后，自动异常处理将导致连接被故意关闭，正如您在此处看到的那样。