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