2017-01-21 3 views
2

私はプロキシの背後でデバッグしていた動作を持つサービスを持っています。プロキシがブラックボックスであるが、サービスの動作は以下のような些細なPythonプログラムでシミュレートすることができます。netcatの-qオプションは正確に何をしますか?

#!/usr/bin/env python 

import socket 
import sys 
import time 

PORT = int(sys.argv[1] or 50007) 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
try: 
    s.bind(('', PORT)) 
    s.listen(1) 
    conn, addr = s.accept() 
    print('conn from %s' % (addr,)) 
    data = conn.recv(1024) 
    time.sleep(1) 
    conn.sendall(data) 
finally: 
    conn.close() 
    s.close() 

私はnetcatを直接これに接続すると、私はいくつかを送った後ということで期待される動作を取得します任意のテキストを改行で標準入力すると、サーバーは1秒間遅れて、それをエコーバックして接続を閉じます。しかし、私がこのサービスをプロキシの背後に置くと、netcatはステータス0()ですぐに終了します。 -qオプションにゼロ以外の数字を付けて、直接接続と同じように動作します。私のシステム上のnetcatのマンページから引用し

-q  after EOF on stdin, wait the specified number of seconds and then quit. 
     If seconds is negative, wait forever. 

私はデバッグしようとしているが接続動作を引き起こすプロキシ接続動作について異なるは何かということです残念なことに、マニュアルページは私を助けてくれていません。それは私の入力ではない(それは私からEOFを受け取ることはありません)、それが参照している "標準"は何ですか? EOFとは、接続を仲介するプロキシがないときに無視する必要がないということから、proxy'dのデータを受け取るのに十分長い間無視しますか?

EDIT:彼らはそれを取得としての基本としてについてですが、ご要望に応じて、ここでは、いくつかのサンプル呼び出しです:

# after starting the example server on <someserver> with <someport 

$ echo foo | nc <someserver> <someport> 
foo 
$ 

# the above, just with -q1 (no change) 
$ echo foo | nc -q1 <someserver> <someport> 
foo 
$ 

# after starting the example server behind the blackbox proxy 
$ echo foo | nc <someproxy> <someproxyport> 
$ 

# same, but with -q 
$ echo foo | nc -q1 <someproxy> <someproxyport> 
foo 
$ 
+0

インタラクティブに、またはリダイレクトされた入力でnetcatを実行しますか? – Leon

+0

使用しているTCPプロキシによっては、プロキシが入力をバッファしている可能性があります。おそらく 'nc'はバッファがフラッシュされてPythonサーバーに転送される前に終了しますか? – dnswlt

+0

@Leonに:両方。 –

答えて

4

echo foo | netcatは、すべての場合にEOFを送信します。違いは、netcatがネットワークソケットを閉じる方法です。

なし-q netcatは、EOFを受信した直後にTCP FINを送信し、TCP接続の半分をシャットダウンします。これは完全な接続終了ではなく、ちょうどan indicationというデータが送信されなくなります。その後、netcatは、接続が終了するまで接続からの印刷データを保持します。

通常のサーバはFINをnetcatから処理しません。遅延はエコー応答を送信し、接続の最後の半分をシャットダウンします。

ブラックボックスプロキシは、すぐに接続を閉じることで、クライアントからのFINに反応するようです。これはサーバー負荷最適化のようなもので、Webブラウザーがたくさんある場合には意味があります。

-q netcatは、接続がサーバーによって閉じられるまで、または-qタイムアウトが終了するまで、FINを送信しません。

tcpdump -wで4つのケースを実行してから、Wiresharkでキャプチャファイルを読み込み、TCPストリームに従ってください。このnetcatの動作はparticular versionに依存する可能性がありますので、Ubuntu 16.04 + netcat-openbsd 1.105で確認します。

+1

TCP FINの洞察をお寄せいただきありがとうございます。これは多くの違いを説明していると思いますので参考にしてください。 –

+0

Do not doあなたは盲目的に信頼してください、とにかくあなたのシステムでtcpdumpを実行してください;)あなたは、同様の将来のすべての質問であなたを助けるスキルを得るでしょう。 – void

+1

心配しないでください。tcpdumpはすでにデバッグプロセスの通常の部分ですが、私はここで私を導いた文脈のおかげで、アプリケーション層に精神的に固執していました –

関連する問題