我希望你能帮忙。我的cloudWatch示例如下。
图像捕获：使用172.0.0.10 的ssh连接日志
正如您所看到的，cloudWatch正在记录请求和响应数据包。在这种情况下，每个人都知道显示22为目的端口的数据包是响应数据包，因为端口22是众所周知的ssh服务器端口
但是，如果它不是已知的端口号，您将无法区分请求和响应数据包。在这种情况下，你如何区分它？cloudwatch日志本身并不能告诉我如何操作。不管我怎么搜索，我都找不到方法。请告知。
在这种情况下，每个人都知道将22显示为目的端口的数据包是响应数据包，因为端口22是众所周知的ssh服务器端口。
这实际上并不正确。恰恰相反。
TCP连接的服务器端使用的是众所周知的端口，而不是客户端¹因此，众所周知的端口是请求的目的地和响应的来源。
源端口为22的数据包将是SSH"响应"(服务器→客户端)分组。目标端口为22的端口将是SSH"请求"(客户端→服务器)分组。
当我向web服务器发出请求时，我的源端口是短暂的，但目标端口是80。响应来自源端口80。
但当然，可以提出这样的论点，即术语"请求"one_answers"响应"并不适用于数据包，但它们适用于数据包中包含的内容——这是特定于协议的。在许多情况下，客户端进行请求，服务器进行响应，但这种相关性并没有清晰地映射到协议栈的底层。
在TCP的情况下，一端总是在侦听连接，通常是在特定的端口上，并且该端口通常是您已知的，如果不是"已知"端口的话，因为您是创建服务并将其配置为在那里侦听的人。
由于这些流日志记录没有捕获识别SYN的源和目标所需的标志。。。同步+确认。。。ACK序列，您无法确定是谁发起了连接。
在不知道"端口22"的知名度或其他意义的情况下，从日志中仍然可以很容易地得出结论，172.0.0.10有一个TCP套接字在侦听该端口，并且许多其他客户端正在从其短暂端口连接到该端口。。。并且我们可以通过在该机器上运行CCD_ 1来确认这仍然在侦听。
¹而不是客户端。在某些情况下，服务器守护进程也是客户端，并将使用已知端口作为传出连接的源端口，因此在这种情况下，source和dest可能是相同的。我相信Sendmail可能就是一个例子，至少在某些情况下是这样，但这些都是例外。