編集：これを書いている時点では、この回答はuWSGIとnginxでのWebSocketサポートの状態を反映しています（それらにはありませんでした）が、それ以来、彼らはそれに対するサポートを増やしてきました。歴史的な興味のために答えはそのままにしておきます。
1：ほぼ確実に、nginxのようなHTTPリバースプロキシが「スプーンフィーディング」の遅いまたは愚かなクライアントプログラムを処理することを望んでいます。一部のユーザーは低速接続になります。リバースプロキシは通常、要求が完全に受信されるのを待ってからアプリケーションに接続し、アプリケーションからの完全な応答をすばやくスラップして（他の要求に進むことができるように）、それをクライアントにフィードバックします。彼らは必要とします。とにかくリバースプロキシを使用している場合は、tcpレベルのロードバランサーを検討する理由もあまりありません。リバースプロキシはすでにその問題を解決できるからです。これは特に当てはまります。tcpロードバランサーはアプリケーションを認識せず、「到達可能」であるが「シック」なアップストリームホストをスキップできないため、「
2：どのアプリケーションコンテナが適切かは、ワークロードの形状だけでなく、アプリケーションにも大きく依存します。tornadoのような非同期コンテナを利用するには、アプリケーションを特別な方法で作成する必要があります。また、wsgiで一般的に利用できる便利で便利なフレームワークのすべてを使用することはできません。一方、長いポーリングや特にWebSocketなどの一部の機能にはこれらが必要になります。これらの機能は、uwsgiなどでは実用的ではありません（または不可能ですらあります）。
ただし、すべてのコンテナが同じように作成されるわけではありません。多くはHTTPのみを話しますが、これはCPUに適したプロトコルではありません。uwsgiのようなコンテナーは、http解析作業を最適化するように設計されているため、リバースプロキシのみがそれを実行する必要があり、そこから、簡単に解析できるバイナリプロトコルが1つのプロセスから次。
3：websocketはまだ非常に新しく、Pythonでのサポートはまばらです。最も成熟したオプションは、トルネードとツイストで利用可能な実装のようです。どちらもuwsgiでホストすることはできず、nginxの背後にプロキシすることもできません。WebSocketを処理できる他のリバースプロキシもありますが、たとえば、ニスです。