（但请注意，可用的 TCP 端口数是每个 IP 地址，而不是全局每个主机 - 如果您有两个 IP 地址，您可以为两个不同的套接字使用相同的端口号，因此只需添加第二个 IPv6 地址就更容易了。理论上它应该是“每个地址对”，所以即使你在连接到服务器 A 时用完了本地端口，你仍然应该能够使用相同的本地端口来连接到服务器 B......）
第 1-3 层上的任何东西会阻止传输包含 32 位 tcp 标头的修改数据包吗？
理论上，什么都不应该。只要您为修改后的 TCP 选择自定义 IP 协议号，它就可以毫无问题地通过 Internet。（住宅 ISP 或锁定的企业网络可能会更挑剔一些，但在公共 Internet 上对非 TCP/UDP 数据包的整体阻止并不常见，并且已经存在许多这样的 - 例如 GRE、ESP、HIP , SCTP...)
从技术上讲是的，但是您只能与同样以完全相同的方式修改的对等方进行通信。因此，您可以同时建立的连接数量不会增加，它会有效地减少到 2-3 个其他也认为这是个好主意的主机。
使用“99% TCP”这一事实没有任何帮助——只要不是 100% TCP，主机仍然不会自动知道如何说它，所以它与部署一个全新的协议相同（比如IL 或 SCTP），这与过去通过增加 32 位地址字段以避免部署 IPv6 来“扩展” IPv4 的尝试类似。
（但请注意，可用的 TCP 端口数是每个 IP 地址，而不是全局每个主机 - 如果您有两个 IP 地址，您可以为两个不同的套接字使用相同的端口号，因此只需添加第二个 IPv6 地址就更容易了。理论上它应该是“每个地址对”，所以即使你在连接到服务器 A 时用完了本地端口，你仍然应该能够使用相同的本地端口来连接到服务器 B......）
理论上，什么都不应该。只要您为修改后的 TCP 选择自定义 IP 协议号，它就可以毫无问题地通过 Internet。（住宅 ISP 或锁定的企业网络可能会更挑剔一些，但在公共 Internet 上对非 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，则会导致混淆。