我的路由器有两个协议（和一个“两个”选项），我可以在设置端口转发时选择：UDP 和 TCP。这两种协议之间有什么区别，您何时会在端口转发中选择一种而不是另一种？
TCP 数据包可以分段到达接收方吗？
例如，如果我使用 TCP 协议发送 20 个字节，我能否 100% 确定我将一次接收 20 个字节，而不是 10 个字节然后再接收 10 个字节左右？
UDP 协议也有同样的问题。
我知道 UDP 是不可靠的，数据包根本无法到达或以不同的顺序到达，但是单个数据包呢？如果它到了，我能确定它是一个完整的包裹，而不是一块吗？
简短版本：我网络上的一台 Windows Server 2012 机器在连接到某些网站时会出现持续但间歇性的 TCP RST。不知道他们从哪里来。查看wireshark日志以了解我的分析和问题。
长版：
我们在其中一台服务器上运行缓存网络代理来为我们的小型办公室提供服务。一位同事报告说，在连接到某些站点时，出现了很多“连接重置”或“页面无法显示”错误，但刷新通常会修复它。
我验证了浏览器行为，然后更直接地通过在服务器本身上尝试未代理的浏览器。但是对麻烦站点的 pings 和 traceroutes 没有显示任何问题，问题似乎仅限于 tcp 连接。
然后我编写了一个脚本来测试受影响的站点，方法是通过 cURL 直接向它们发送 HTTP HEAD 请求并检查它们成功的频率。一个典型的测试看起来像这样：（这是未经代理的，直接在坏服务器上运行）
C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0 Response Code: NULL (0%)
20:22:02: Length: 0 Response Code: NULL (0%)
20:22:22: Length: 0 Response Code: NULL (0%)
20:22:42: Length: 0 Response Code: NULL (0%)
20:23:02: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174 Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: …我花了一些时间研究这个话题，似乎找不到确切的答案，所以我相当有信心它不是重复的，虽然我的问题是基于安全需要，但我认为它仍然是安全的在这里问，但如果我需要将其转移到安全社区，请告诉我。
本质上，DNS 查询是否曾经使用 TCP（如果是，会发生什么情况）？同样，我只是在谈论查询。它们是否可以通过 TCP 传输？如果域的最大长度只能为 253 个字节，而 UDP 数据包的最大长度为 512 个字节，那么查询不会总是以 UDP 的形式发出吗？我不认为可解析的查询大到需要使用 TCP。如果 DNS 服务器收到对大于 253 字节的域的请求，服务器会丢弃它/不尝试解析它吗？我确定我在这里做了一些错误的假设。
在某些情况下，我正在与安全组合作将 DNS 查询加载到他们的安全监控工具中，出于各种原因，我们决定通过 DNS 服务器和域控制器上的标准数据包捕获来捕获此流量。核心要求是捕获所有 DNS 查询，以便他们可以识别尝试解析任何给定域的客户端。基于此要求，我们不关心捕获 DNS 响应或其他流量（如区域传输），这也是由我们需要尽可能限制日志量这一事实驱动的。因此，我们计划仅捕获发往 DNS 服务器并通过 UDP 发送的 DNS 查询。对于更多上下文（这里的问题范围正在蔓延），现在有人提出我们可能需要扩展安全性” s 可见性，因此他们可以监视活动，例如通过 DNS 运行的隐蔽通道（这也需要捕获 DNS 响应，以及随后的 TCP 流量）。但即使在那种情况下，我认为任何出站 DNS 流量都将采用查找/查询的形式，并且这些流量始终通过 UDP，即使来自恶意来源（因为我在第一段中的推理）。所以这带来了一些额外的问题：
我们至少会用我概述的方法捕获一半的对话吗？或者客户端是否会发送非查询形式的 DNS 流量？（也许就像对 DNS 服务器响应的某种回复，最终可能会通过 TCP 发送出去）
是否可以修改 DNS 查询以使用 TCP？DNS 服务器会接受并响应来自 TCP 的 DNS 查询吗？
不确定它是否相关，但我们确实将 DNS 请求限制为授权的 DNS 服务器并阻止所有其他通过端口 53 出站的流量。我绝对是一个菜鸟，所以如果我的问题不合规，我很抱歉，并让我知道我应该如何修改。
Windows 中的默认 TCP 连接超时时间是多少？有一个注册表项来配置它还是动态设置？
我有一个带有这些简单规则的防火墙：
iptables -A INPUT -p tcp -s 127.0.0.1/32 --dport 6000 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.16.20/32 --dport 6000 -j ACCEPT
iptables -A INPUT -p tcp --dport 6000 -j REJECT
现在，假设我像这样使用TCPDUMP：
tcpdump port 6000
我有主机192.168.16.21试图连接到端口6000。
将/应该tcpdump输出一些来自192.168.16.21?
最近我们有一个 apache 服务器，由于 SYN 泛滥，它的响应非常缓慢。解决方法是启用 tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf)。
如果您想要更多背景知识，我在这里发布了一个关于此的问题。
启用 syncookies 后，我们开始大约每 60 秒在 /var/log/messages 中看到以下消息：
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic 告诉我，这意味着 syn backlog 已满，所以我将 tcp_max_syn_backlog 提高到 4096。在某些时候，我还通过发出sysctl -w net.ipv4.tcp_synack_retries=3. 这样做之后，频率似乎下降了，消息的间隔在大约 60 到 180 秒之间变化。
接下来我发出了sysctl -w net.ipv4.tcp_max_syn_backlog=65536，但仍然在日志中收到消息。
在所有这一切中，我一直在观察处于 SYN_RECV 状态的连接数（通过运行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'），它永远不会高于大约 240，远低于积压的大小。但是我有一个 Red Hat 服务器，它在 512 左右徘徊（此服务器的限制是默认值 1024）。
是否有任何其他 tcp 设置会限制积压的大小，或者我是否在咆哮错误的树？SYN_RECV 连接的数量是否应该netstat -tuna与积压的大小相关？
尽我所能，我正在处理这里的合法连接， …
这是一个关于 iSCSI的规范问题，我们可以用作参考。
iSCSI 是一种将 SCSI 命令作为有效负载放入 TCP 网络数据包的协议。因此，它会遇到一系列与光纤通道不同的问题。例如，如果链路拥塞并且交换机的缓冲区已满，默认情况下以太网将丢弃帧而不是告诉主机减速。这会导致重传，从而导致极小部分存储流量的高延迟。
有针对此问题的解决方案，具体取决于客户端操作系统，包括修改网络设置。对于以下操作系统列表，最佳 iSCSI 客户端配置是什么样的？它会涉及更改开关上的设置吗？存储呢？
我想知道如何继续排除对网络服务器的 curl 请求不起作用的原因。我不是在寻求依赖于我的环境的帮助，我只是想知道如何收集有关通信的确切部分失败、端口号等的信息。
chad-integration:~ # curl -v 111.222.159.30
* About to connect() to 111.222.159.30 port 80 (#0)
* Trying 111.222.159.30... connected
* Connected to 111.222.159.30 (111.222.159.30) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: 111.222.159.30
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 111.222.159.30 left intact
curl: (52) Empty reply from server
* Closing connection #0
所以，我知道空响应意味着 curl 没有从服务器得到任何响应。没问题，这正是我想要弄清楚的。
但是我可以从这里的 cURL 获得哪些更具体的信息？
它能够成功“连接”，所以这不涉及一些双向通信吗？如果是这样，那么为什么响应也没有来？请注意，我已验证我的服务已启动并返回响应。
请注意，我对这个级别的网络有点陌生，所以请随意提供一些一般性的介绍材料。