低レベルネットワークプログラミングを理解するための道具箱 - Qiita
はじめに TCPの仕様やconnect、write、read等のソケット関連のシステムコールの振る舞いを正確に理解するのはとても難しい。 正常系はそうでもないが、「どの程度パケットは再送されるのか」、「〜状態で〜のシステムコールはどのerrnoを返すのか」など異常系が難しい。また、これらの情報はWEB上だと良質な情報が比較的少ないように思う。 ここでは、挙動の説明は諦め1、挙動を確認するためのコマンドやコード群を紹介したい。 なお、普通のバックエンドエンジニアをしている人間で、ネットワークのスペシャリストではないので間違っている可能性は多分にある。ただ、ここで説明することは全て動作確認はしている。動作確認した環境はこちらにある。 コマンド 説明 ss -tanpo tcp(t)の全状態(a)をポート番号のまま(n)プロセス情報(p)とタイマー情報付き(o)で表示する。 ssは継続的な状態確
tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話 - Qiita
tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話CTCP はじめに サーバがコネクションをclose後しばらくして、クライアントがwriteしました。関数呼び出しの結果はエラーでしょうか？ 上記の正解は「何事もなく、成功する」です。この挙動が理解できている方はこの記事を読む必要はないかもしれません。 自分は「接続先がcloseしたソケットにwriteした場合はプロセスがSIG-PIPEを受け取るかシグナルをハンドリングしていた場合はEPIPEが返ってくる」と思っていました。 それは、Linuxのマニュアルに以下の記載があるためです。 EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writin
Goのhttp.Requestのキャンセルの仕組みを理解する - Qiita
はじめに Goのhttp.Request構造体のctxはdocによると、以下の場合にcancelされます。 For outgoing client requests, the context controls cancellation. For incoming server requests, the context is canceled when the client's connection closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns. クライアントがタイムアウトを設定していた場合にもタイムアウト時間経過後にコネクションがcloseされるため、サーバ側実装でcontextを参照することでタイムアウトしたことも気づけることになります。 Request.ctxやそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
