gen_tcp:accept/1 安全吗？
我正在实现一个接受许多并发连接的服务器。
我使用了这个结构：
loop(Sock) ->
case gen_tcp:accept(Sock) of
{ok, CSock} ->
fork_handling_process(CSock);
{error, Reason} ->
do_something_else();
end,
loop(Sock).
我想知道如果有人向我发送 SYN，但从未向我发送 SYN ACK 来响应我的服务器 ACK，那么自从我调用 gen_tcp:accept 而没有超时后，我的服务器是否会被该客户端永远阻止？
顺便说一句，我认为这种情况很难模仿，所以如果你有办法尝试一下，请告诉我。
提前谢谢。
I am implementing a server which accepts many concurrent connections.
I used this structure:
loop(Sock) ->
case gen_tcp:accept(Sock) of
{ok, CSock} ->
fork_handling_process(CSock);
{error, Reason} ->
do_something_else();
end,
loop(Sock).
I am wondering if someone sends me a SYN, but never sends me an SYN ACK in response to my server ACK, will my server be blocked forever by that client since I call gen_tcp:accept without a timeout?
By the way I think this situation is hard to emulate, so please let me know if you have ways to try it out.
Thx in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您监听/接受时，它与您所描述的有点不同：
某些客户端想要连接：它发送一个SYN，然后您的操作系统发送一个SYN/ACK（erlang不涉及），当您收到ACK时gen_tcp：accept将返回。
当有人向您发送 SYN 而没有其他任何内容时（如果发送的数量过多，这将是 SYN 洪水攻击），那么操作系统资源将被保留，但您的 erlang 代码中不会发生任何事情，因为三向握手尚未完成。
许多操作系统都特别注意 SYN 洪泛攻击，以避免过多的资源消耗。
When you listen/accept its a bit different as you describe:
Some client wants to connect: it sends a SYN, then your operating system sends a SYN/ACK (erlang not involvled), when you get the ACK gen_tcp:accept will return.
When someone sends you SYN's and nothing else (that would be a SYN flood attack if done in a great amount) then operating system resources will be reserved but nothing happens in your erlang code because a three way handshake is not complete yet.
Many operating systems are taking special care of SYN flooding attacks avoiding too much resource consumption.
您使用的方法似乎没问题。您的服务器不会阻塞。如果出现问题，我相信您的分叉进程将收到错误，而不是服务器。
The approach you are using appears to be fine. Your server will not block. If something goes wrong I believe that your forked process will receive the error, not the server.