https://www.ap-siken.com/kakomon/30_aki/pm05.html
本文中の〔不具合事象の切分け〕に「Webサーバ1～3で利用可能なTCPポートが一時的に枯渇する事象が発生していることが分かった。」とありますが、TCPポートが枯渇する事象というのは、ソケットが枯渇することとはまた違う事象でしょうか？
令和元年秋期午後のネットワークの問題がソケットの枯渇について扱っていて、違いがわからないため質問させていただきました。

このサーバがUnix/Linux（as *nix）なら、結局枯渇と言うのがファイルディスクリプターの限界、つまりTCPコネクションをファイルとして開いて、閉じなければファイルディスクリプターが開きっぱなしになるので、ソケット（TCPコネクション）が枯渇するわけですよ。

これがTCPポートの枯渇の話になってくると、2段階あって、
①Linuxのファイルディスクリプターの限界（デフォルトが60000）が来た
②エフェメラルポート（ダイナミックポート、32768-60999ポートがそれなので28232ポート）がネットワーク接続のたびに通信の数だけ（※）消費される（通信終了段階で解放されるが、通信が終了していなければ解放されない）わけで、それの限界が来た
※1つのアプリケーションでも大量に通信をするとポート番号が尽きることはあり得る
これの原則だけ見るとエフェメラルポートのほうがファイルディスクリプターより少ないからエフェメラルポートのが原因じゃないかと考えたいところですが、ファイルディスクリプターはネットワークに限らずLinuxの所作すべてにかかわってくるので、たとえばリクエストに限らずレスポンスに至る過程でサーバサイドアプリケーションがFile I/Oで大量のファイルをZip圧縮とかしているとして、解放（close）しないままバカスカ次から次へと通信していたら当然それでファイルディスクリプター起因でなにもかも失敗するようになる（解放には再起動しかない）ので、原因は実際問題どっちにあるかはそのときによるわけです。ま、昔私がそのバカをやったんですけどね
しかしまあ、エフェメラルポート数分までTIME_WAITで埋め尽くされたら、セッションを作れないことになるからそういうのを「TCPの」枯渇といっているわけです。

なるほど、ソケットとポートの枯渇についてやっと理解できました。ファイルディスクリプター、エフェメラルポートについてよく知らなかったためとても勉強になりました。
具体例など交えた非常にわかりやすく丁寧な回答ありがとうございました。