我希望你的帮助。 我的cloudWatch示例如下。
image capture: ssh connection logs with 172.0.0.10
如您所见，cloudWatch正在记录请求和响应数据包。 在这种情况下，每个人都知道显示22作为目标端口的数据包是响应数据包，因为端口22是众所周知的ssh服务器端口。
但是，如果它不是众所周知的端口号，您将无法区分请求和响应数据包。在这种情况下你如何区分它？仅云计划日志并没有告诉我如何。无论我如何谷歌，我都找不到办法。请指教。
答案 0 :(得分：0)
在这种情况下，每个人都知道显示22作为目标端口的数据包是响应数据包，因为端口22是众所周知的ssh服务器端口。
这实际上并不正确。情况正好相反。
TCP连接的服务器端使用众所周知的端口，而不是客户端¹，因此众所周知的端口是请求的目的地和响应源。
source 端口为22的数据包将是SSH“响应”（服务器→客户端）数据包。 destination 端口为22的端口将是SSH“请求”（客户端→服务器）数据包。
当我向Web服务器发出请求时，我的源端口是短暂的，但目标端口是80.响应来自源端口80.
但是，当然，可以认为“请求”和“响应”这两个术语并不适用于数据包， 但它们适用于数据包包含的内容 - 这是协议特定的。在许多情况下，客户端执行请求并且服务器执行响应，但该关联不会干净地映射到协议堆栈的低层。
在TCP的情况下，一方总是在侦听连接，通常是在特定端口上，并且如果不是“众所周知的”端口，那么该端口通常是您所知道的，因为您是创建该端口的人。服务并将其配置为在那里收听。
由于这些流日志记录不捕获识别SYN ... SYN + ACK ... ACK序列的源和目的地所需的标志，因此无法确定谁发起了连接。
由于不了解“端口22”的众所周知或其他重要性，从您的日志中可以很容易地得出结论172.0.0.10有一个TCP套接字侦听该端口以及其他众多客户端从他们短暂的端口连接到它...我们可以通过在该机器上运行netstat -tln来确认它仍在监听。
¹大部分时间都不是客户。在某些情况下，服务器守护程序也是客户端，并且将使用已知端口作为传出连接的源端口，因此在这种情况下source和dest可能相同。我相信Sendmail可能就是一个例子，至少在某些情况下，但这些都是例外。
