我在读这我开始怀疑是否有任何东西阻止我修改 Linux TCP 堆栈的副本以支持超过 16 位的标头，从而允许更多端口。这是否可行？如果可行，那么第 1-3 层上是否有任何东西阻止传输包含 32 位 TCP 标头的修改数据包？
答案1
这可能吗？
从技术上来说可以，但你只能与还已经以完全相同的方式进行了修改。因此，您可以同时建立的连接数量不会增加，而是会有效地减少另外 2-3 位主持人也认为这是一个好主意。
即使您使用“99％TCP”也无济于事——只要它不是 100％TCP，主机仍然不会自动知道如何使用它，因此这与部署全新的协议（如 IL 或 SCTP）相同，并且与过去通过增加 32 位地址字段来“扩展”IPv4 以避免部署 IPv6 的尝试类似。
（但请注意，可用的 TCP 端口数量是每个 IP 地址，不是每个主机全局的——如果您有两个 IP 地址，则可以对两个不同的套接字使用相同的端口号，因此只需添加第二个 IPv6 地址就更容易了。理论上它应该是“每个地址对”，因此即使您在连接到服务器 A 时用完了本地端口，您仍然应该能够使用相同的本地端口连接到服务器 B...）
1-3 层上的任何东西是否会阻止包含 32 位 tcp 标头的修改后的数据包的传输？
理论上，没什么。只要你为修改后的 TCP 选择自定义 IP 协议号，它应该可以毫无问题地在互联网上传输。（住宅 ISP 或封闭的企业网络可能会更挑剔一些，但总体而言，在公共互联网上阻止非 TCP/UDP 数据包并不常见，而且已经存在许多此类情况 - 例如 GRE、ESP、HIP、SCTP...）
（一些 L2 和 L3 功能（相应的 LACP 和 ECMP）实际上会查看更高层的标头，但是当它们看到未知的 L4 协议时它们不会直接失败 - 我认为它们的性能最多可能会比本来的更差。同样，您的第 1 层接口 - 以太网卡 - 通常具有硬件 TCP 校验和和分段卸载，这不适用于修改后的 TCP，但这再次只是性能损失，而不是关键问题。）
在实践中，不过，防火墙可能会让你非常头疼。家庭路由器（或各种云提供商）中的带 NAT 的状态防火墙和企业路由器中的无状态过滤器（实际上可以将 TCP 报头布局嵌入硬件中）。
这就是为什么 SCTP 尽管具有 TCP 所缺乏的几个理想特性却从未真正流行起来的原因之一，也是为什么 QUIC 被设计为依赖 UDP 作为其多路复用层而不是成为具有自己的端口字段的 IP 级协议的原因。
例如，如果您使用修改后的 TCP 建立出站连接，则家庭路由器中的状态防火墙可能无法正确允许数据包返回 - 它必须识别 L4 协议以跟踪其端口（或 ID 或 SPI 或等效项） - 更重要的是，如果您在 IPv4 上执行此操作，NAT 功能将无法正确转换数据包（地址转换需要更新 TCP 校验和）。
在 NAT 后面使用现有的非 TCP/UDP 协议（例如 IPIP 或 GRE）的常见情况是 NAT 仅记住一个内部设备根据协议（由于无法访问端口号），因此如果多个主机尝试通过同一网关使用 IPIP 隧道，则其 NAT 状态可能会坚持使用首先通话的主机（阻止所有其他主机在状态过期之前使用该协议）或可能继续重置为最后通话的主机（因此，发往主机 A 的入站数据包将被传送到主机 B，等等）。
即使是很少使用的协议是标准和做当廉价网关在其 NAT/防火墙中不包含必要的模块（由于资源限制）时，传统端口（例如 SCTP 或 DCCP）已经遭受这些问题。
如果你试图通过对修改后的 TCP 重新使用现有的 TCP 协议号来避免这些问题，那么事情反而会变得更糟——防火墙会误解你的 32 位端口字段为原始的 16 位字段对，等等。
与其修改基本报头，更好的方法可能是保留标准 TCP 并使用TCP 选项携带额外的 16+16 位——这对于无法识别这些选项的主机或网关仍然没有帮助，但至少您可以按照当前部署的系统已经期望的方式执行此操作。（多路径 TCP 以这种方式部署在某种程度上是成功的。）
但是，即使您使用 TCP 选项来增加端口位，许多问题仍会存在。例如，现有的 NAT 系统仍然只会查看端口号的低 16 位，如果同时使用端口 80 和 65616，则会引起混淆。