hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
アンチモン 用途
アンチモンの生産量の約60％は難燃剤に使用され、20％が鉛電池、残りがすべり軸受、はんだの合金などで使用される。工業材料として多岐にわたる用途に用いられているが、人体に対して毒性の疑いがある（化合物の多くが刺激性のある劇物）ことから、代替素材の開発が進み、徐々に使用が控えられる傾向にある。アンチモン地金は正方形に作られることが多く、上方に輝安鉱のようなシダ状の凸凹模様ができる。これは「スターマーク」と言い、純度の高い物ほど、この模様がはっきりと現れる。もろい金属のため合金として用いられ、16世紀には鏡や活字（活字合金）に用いられていた。
主に防炎コンパウンドの三酸化物として使用され、ハロゲン含有ポリマーを除いて常にハロゲン化難燃剤と組み合わせて使用される。三酸化アンチモンの難燃効果は水素原子と反応して酸素原子とOHラジカルとも反応して火災を抑制するハロゲン化アンチモン化合物の形成によって生み出される。
これらの難燃剤の市場には、子供服、おもちゃ、航空機、自動車のシートカバーなどがある。
アンチモン 用途
鉛蓄電池の電極への添加は強度及び帯電特性を向上させ電池の性能を向上させる。
アンチモンは鉛と非常に有用な合金を形成して硬度と機械的強度を高める。鉛を含むほとんどの用途はさまざまな量のアンチモンが合金金属として使用される。また、一般的な熱膨張特性に反して溶融状態から冷え固まる際に膨張する特性を利用し活字合金などヒケ（収縮による凹みや歪み）を防止する高精度鋳物を作れる。大型の帆走スーパーヨットの場合は船底のバラストとして鉛キールが使用される。鉛キールの硬度と引張強度を向上させるために2〜5体積%のアンチモンが鉛に混合される。銃弾の弾頭の鉛への添加（硬鉛）、電気ケーブル、鉛ハンダ、オルガンパイプなどがある。
ガラス製造工程で、溶融したガラスに三酸化物を混和する事で、泡抜きを助け、製品の透明度を高める。
アンチモン 毒性
周期律表でヒ素の下に位置し、化学的性質に類似性がある。「ヴァレンティヌス文書」などを始め古典的著作には毒性が認められてきた元素である。
急性アンチモン中毒の症状は、著しい体重の減少、脱毛、皮膚の乾燥、鱗片状の皮膚である。また、血液学的所見では好酸球の増加が、病理的所見では心臓、肝臓、腎臓に急性の鬱血が認められる。このほか、アンチモン化合物は、皮膚や粘膜への刺激性を有するものが多く、日本では毒物及び劇物取締法及び毒物及び劇物指定令によりアンチモン化合物及びこれを含有する製剤は硫化アンチモンなど一部の例外を除いて劇物に指定されている。
19世紀のイギリスで義母・弟・子供など多くの人物を毒殺した疑いのあるウィリアム・パーマーの妻アン（1854年9月死亡）の遺体からアンチモンが検出されている。
同じくイギリスの毒殺連続殺人犯であるグレアム・ヤング（1947年 - 1990年）は少年時代からアンチモンを「小さな相棒」と呼ぶほど溺愛しており、家族や友人、同級生や同僚など彼の人生に関わったほぼ全ての人間に致死量のアンチモンを摂取させて中毒症状に陥れた。立件された殺害数は3名のみだが、彼の関与が強く疑われるも証拠不十分となった死亡事件や重度の後遺症から後に自殺や病死をした被害者も数多い。
アンチモン 産地
中国の湖南省が世界の主産地で、他に広東省、貴州省などにも輝安鉱の鉱山がある。最大の鉱山は湖南省の錫鉱山であるが、その名が示す通り、昔はスズと混同されていた。なお、中国語の方言では、アルミニウムをアンチモンやスズと混同して呼ぶ例も見られる。
日本において本格的に採掘が開始されたのは明治時代以降である。愛媛県・市ノ川鉱山、兵庫県・中瀬鉱山（金山として開発され、第二次世界大戦後にアンチモンが主力となった）、山口県・鹿野鉱山等が開発された。とくに市ノ川鉱山は美晶の輝安鉱が産出されることが海外にも知られ、製錬所も建設された。しかし、資源枯渇や生産コストの問題から現在は全て輸入となっている。また、鉱石による輸入は1990年代に終了し、全量が地金及び地金屑、あるいは三酸化アンチモン等化合物による輸入である。
2011年5月、鹿児島湾の海底で総量約90万トンと推定されるアンチモンの鉱床が、岡山大学や東京大学、九州大学らの研究グループにより発見されたと報道された。2010年の日本国内販売量約5千トンから計算すると、約180年分がまかなえる量。
アンチモン 歴史
アンチモン化合物は古代より顔料（化粧品）として利用され、最古のものでは有史前のアフリカで利用されていた痕跡が残っている。
西洋史においてはドイツ・エルフルトのベネディクト会修道院長、医師、錬金術師であるBasil Valentineが著したとされる『太古の偉大なる石』『自然・超自然の存在』『オカルト哲学』『アンチモン凱旋車』など「ヴァレンティヌス文書」にアンチモンの記述が見出される。しかし、ベネディクト会の記録にはバシリウス・ウァレンティウスが存在したという記録はない。また、16世紀にテューリンゲンの参事官かつ製塩業者であるヨハン・テルデが編纂出版しているが、実際にはウァレンティウスは存在せず彼の著作であるという説がある。
『アンチモンの凱旋車』でワインより生じる「星状レグレス」と呼ばれる結晶が記述されているが、これは酒石酸アンチモニルカリウム（三水和物）の結晶であると推定される。またアンチモンの毒性について「ヴァレンティヌス文書」で述べられている。
日本最古の銅銭である富本銭（683年頃）に、アンチモンが銅の融解温度を下げ鋳造を易しくするとともに、完成品の強度を上げるために添加されている。
アンチモン 名称
アンチモン（Sb）の元素記号Sbは輝安鉱（三硫化二アンチモン、Sb2S3）を意味するラテン語 Stibium を省略して、イェンス・ベルセリウスが使用し始めた。古代において、アンチモンを指す言葉は、主に硫化アンチモンを主成分とするコール（khol）を意味していた。日本では、英語の読み方を採用してアンチモニー（安質母尼）と表記されている事もある（合金としてのアンチモニーについては後述）。
アンチモンの名称の元々の起源は諸説あり、いまだ定説がない。しかし、現代語および後期ビザンチン・ギリシャ語におけるアンチモンの名称は、中世ラテン語形であるantimoniumに由来することが分かっている（アラビア語起源説を参照）。
その起源については、いくつかの説が提唱されている。
アンチモン 名称
ギリシャ語で「孤独嫌い」を意味するanti-monosに由来するという説がある。これは、アンチモンが自然界において単体では産出せず、必ず他の元素と化合した合金で発見されるという事実を反映していると考えられる。ただし、古代ギリシャ語では、否定を表す接頭辞として α- ("not") を用いるのがより自然であるため、この説には疑問が残る。Edmund Oscar von Lippmannは、仮説的なギリシャ語 ανθήμόνιον (anthemonion) を提唱している。これは「小花」を意味し、Lippmann は化学的あるいは生物学的な風解（または白華）を記述する関連ギリシャ語の例を複数挙げている（ただし、anthemonion自体は含まれない）。
アンチモン 名称
11世紀頃（1050～1100年）にコンスタンティヌス・アフリカヌスによって翻訳されたアラビア語の医学書に、すでにantimoniumという語が使われていたことから、antimoniumという語はアラビア語に由来する可能性も指摘されている。この説を支持する研究者の一人であるMax Meyerhof は、antimoniumはアラビア語のithmidまたはathmoudが、中世の「野蛮なラテン語翻訳（traductions barbaro-latines）」によって誤って訳されたものだと主張している。また、Oxford English Dictionaryもアラビア語起源説を有力視しており、ithmid を語源とするならば、athimodium、atimodium、atimoniumといった中間的な形を経由した可能性を示唆している。ちなみに、アラビア語では、アンチモンは現在でもإثمد (ithmid)と表記されている。過去には、athmoud、othmod、uthmod などと表記されていた。
アンチモン 名称
その他にも、更に深堀りをして、アラビア語でメタロイドを指すathimarや、ギリシャ語のstimmiに由来するか、またはそれと同等の意味を持つ仮説的な as-stimmi などの可能性が考えられている。Émile Littréは、最も初期の形式であるithmidは、ギリシャ語stimmiの対格であるstimmidaに由来すると示唆している。また、エジプトでは、アンチモンはmśdmtまたはstmと呼ばれていたが、ギリシャ語の στίμμι (stimmi) は、紀元前5世紀のアッティカの悲劇詩人によって使用されており、アラビア語またはエジプト語のstmからの借用語である可能性がある。
フランス語のantimoineに基づいた、「修道士殺し」を意味する anti-monachos という語に由来するという説がある。これは、初期の錬金術師の多くが修道士であり、一部のアンチモン化合物が毒性を持つという事実によって説明される。なお「ある修道会で豚にアンチモンを与えたら（駆虫薬として働き）豚は丸々と太った。そこで栄養失調の修道士に与えたところ、太るどころではなく死んでしまった。それゆえアンチ・モンク（修道士に抗する）という名が与えられた」という逸話があるが、俗説であろうと考えられている。
日本語でアンチモニーと呼ばれる場合、この元素（英語名）ではなくこの元素を含む合金の一種を指す場合がある。
合金としてのアンチモニーは、鉛80%〜90%、アンチモン10%〜20%、このほか用途により錫（スズ）を少々混ぜた合金のことをいう。合金としてのアンチモニーの地金を鋳造加工した製品をアンチモニー製品、その産業をアンチモニー産業という。
合金としてのアンチモニーは鋳物表面（鋳肌）が平滑で、冷却後の収縮が少なく、メッキの乗りも良いといった特性がある。小皿、優勝カップ、トロフィー、メダルなどに利用される。
機動戦士VS伝説巨神 逆襲のギガンティス
『機動戦士VS伝説巨神 逆襲のギガンティス』（きどうせんしたいでんせつきょじん ぎゃくしゅうのギガンティス、GUNDAM VS. IDEON）は、矢立肇・富野由悠季（原案）、長谷川裕一（漫画）による日本の漫画作品である。
機動戦士VS伝説巨神 逆襲のギガンティス 概要
アニメ作品群「ガンダムシリーズ」と『伝説巨神イデオン』を題材とするクロスオーバー作品。バンダイ出版課の漫画雑誌『サイバーコミックス』No.23 - 26に『ガンダムVS伝説の巨神』（ガンダムたいでんせつのきょじん）として連載された。その後、単行本化の際に現在の題名へと改められている。
宇宙世紀を舞台にしており、本作が執筆された1990年におけるテレビアニメ『機動戦士ガンダムΖΖ』と劇場アニメ『機動戦士ガンダム 逆襲のシャア』の期間をつなぐ「仮想作品」として描かれている。
機動戦士VS伝説巨神 逆襲のギガンティス 制作背景
ある時、長谷川は友人のこやま基夫にガイナックスの忘年会へ誘われる。そこで知り合った『サイバーコミックス』の編集者にガンダム漫画の執筆を依頼され、年明けに正式な依頼の電話が来た。この時、編集者は「サンライズはもうアムロもシャアも使わないから好きに描いていい」と述べたというが、長谷川は「自分の気を削がないように言ってくれたのかもしれない」と回想している。
長谷川は学生時代に考えていた「ガンダムVSイデオン」を描きたいと話したが、編集者にはギャグ漫画と思われたらしく、大笑いされた。さすがに「ガンダムVSイデオン」はまずいということで「ガンダムVS伝説の巨神」というタイトルとなった。話数は全3話を予定していたが、収まりが悪かったため全4話となったという。
発想は「東映まんがまつり」の『マジンガーZ対デビルマン』などと同様のものであり、長谷川には同じ制作会社の作品は対決するものであるというイメージが何となくあった。また、終盤のジュドー・アーシタの台詞には『無敵鋼人ダイターン3』からの引き写しがある。
機動戦士VS伝説巨神 逆襲のギガンティス 物語
宇宙世紀0091年、木星圏で働いていたジュドー・アーシタは、地球からの船と共にやって来たアムロ・レイの来訪を受ける。アムロは木星圏でジオンの残党が100メートル級の超大型モビルスーツを開発しているという動きを察知し、それを阻止すべくやって来たのだという。その超大型モビルスーツらしきものは、木星出身の小説家ヨシユキ・トミノのフィクション作品に登場する人型ロボットにちなんで「伝説巨神」というコードネームで呼ばれていた。アムロは漠然と、小説の中で人類を見限り宇宙を滅ぼした「伝説巨神」は実在すると考えていた。
アムロの部下であるシマ・八丈と鉄面皮、そしてモビルスーツ「メガゼータ」に乗るジュドーとアムロの4名は、小惑星の背に固定されている「伝説巨神」とジオン残党の基地を発見。シマと鉄面皮が囮になり、その隙にジュドーとアムロが「伝説巨神」の内部に乗り込むも、助けを求める何者かの声を感じ取ったジュドーは単独行動を開始し、やがてサイコミュ装置に繋がれ囚われていたミネバ・ザビを発見する。ジュドーはミネバを連れて脱出しようとするが、基地司令官のヒトーリンが、ジュドーこそがミネバの敬愛するハマーン・カーンを殺害した張本人であると吹き込む。そして、ミネバの絶叫と共に「伝説巨神」は動き出す。
機動戦士VS伝説巨神 逆襲のギガンティス 物語
「伝説巨神」はヨシユキ・トミノの小説に登場する巨神そのものであり、巨神が夢として見せた「警告」を書き留めたものがヨシユキ・トミノの小説であった。全てを圧倒する巨神の力にジュドー、アムロ、シマ、鉄面皮、そしてシャアが苦戦を強いられる中、ジュドーは巨神に取り込まれたミネバの救出を試みる。
再び巨神の中に潜入したジュドーは、彼を「かつて有機宇宙（ユウキ・コスモ）だったものの一部」と呼ぶ者、「無限力」の声を聞く。無限力はかつて、宇宙そのものをも終局に導くほどの激しい争いを繰り広げていた二つの民の憎しみを利用して自ら宇宙を滅ぼし、その後、人が再び過ちを犯さないように「互いにわかり合うための力」を分け与えた。だが、人はなお争いをやめなかったため、再び宇宙を無に帰そうとしているのだという。無限力はこれを「死」ではなく「やり直し」だとし、受け入れることを強要するが、ジュドーはこの考えを否定する。
ミネバはジュドーによって救出され、巨神はアムロとシャアの攻撃で破壊される。戦いの後、アムロはシャアとの戦いのため地球圏に戻り、ミネバはアムロの図らいにより「ミネバ・アーシタ」としてジュドーの元に残される。
機動戦士VS伝説巨神 逆襲のギガンティス 登場人物
ジュドー・アーシタ
かつて第一次ネオ・ジオン抗争でΖΖガンダムに乗り戦った英雄。現在は木星圏のスペースコロニー「オリュンポス・コロニー」で暮らしている。もう二度と軍には関わらないと決めていたが、第二の故郷である木星圏の平和を守るため、アムロに手を貸すことを決意する。
本作におけるニュータイプ（ジュドー、アムロ、シャア）は『伝説巨神イデオン』の主人公ユウキ・コスモの生まれ変わりであるとされている。ジュドーはその中で最も色濃くコスモの因子を受け継いでいるらしく、無限力からは「コスモ」と呼ばれる。
作中、アムロの考えが本当かどうか確かめたり、ミネバに自分が敵ではないことを教えるためにニュータイプ能力を使っているが、一方でその力を戦いの場で発揮することはなく、またカミーユ・ビダンがパプテマス・シロッコとの決戦で行ったような、死者の思念を取り込み力にすることを否定し（ハマーン、プル、プルツー、ララァらの霊が力を貸そうとするが拒否する）、「生きている者の力」でミネバを救出するなど、ニュータイプの力に頼るまいとしている。
アムロは、不必要な時にはニュータイプ能力を使わず「閉じておく」ことができるジュドーは、彼より以前にニュータイプと呼ばれた者たちよりも進化した個体であるという仮説を立てている。
機動戦士VS伝説巨神 逆襲のギガンティス 登場人物
アムロ・レイ
超大型モビルスーツの調査のため非公式に木星圏に現れた、かつての英雄的存在。ジュドーと共にメガゼータに乗ってジオン残党および巨神と戦い、途中から参戦したシャアと「最初で最後の共同戦線」を張る。ラストでは「ミネバ・アーシタ」の処遇について便宜を図る。
正史においては、宇宙世紀0091年当時のアムロはロンド・ベルの結成に関わっていたことになっているものの、本作では「当時の公式な記録に登場するアムロは影武者であった」という、独自の設定を用いている。
無限力によれば、彼とシャアもまたユウキ・コスモの生まれ変わりだという。
シマ・八丈（シマ・ハチジョウ）
アムロと共に木星圏に来た女性パイロットだが、専門はデータ分析。鉄面皮と共に、連邦軍内でも屈指のニュータイプ能力者であるとされる。
鉄面皮（てつめんぴ）
アムロと共に木星圏に来たパイロット。仮面を着けた男性。本名は不明。
シマと共にメガゼータの援護を行う。アムロやジュドーからは火傷を隠すために仮面を着けているのだろうと思われていたが、実は対人赤面症で、軍務に支障が出ないように隠していただけであった。素顔は美形で、それを知ったアムロは苦笑する。
ミネバ・ザビ
機動戦士VS伝説巨神 逆襲のギガンティス 登場人物
「伝説巨神」を稼動させるためのキーとしてヒトーリンに拘束されている。ニュータイプ能力による精神感応でジュドーを信用するが、姉と慕っていたハマーンを殺したのがジュドーであると吹き込まれ、彼女の絶望に呼応して巨神が覚醒する。
ヒトーリン
木星圏で「伝説巨神」破壊計画を担当していた士官。枠外で「注：地球人」と注釈が打たれるほど、人相も体型も醜い豚のような小男。
ネオ・ジオン本隊からの命令を無視し、巨神の力で地球連邦を壊滅させ「神聖ジオン帝国」を作ろうと目論んでいた。最後はザク型のデコプチでオリュンポス・コロニーに逃げ込もうとするが、シャアのスザクに撃ち落とされ死亡。その後、他の戦死者たちと共に魂を無限力に取り込まれる。
シャア・アズナブル
巨神の復活を知り、ヒトーリンと巨神を止めるためにネオ・ジオンの大部隊を率いて現れた。ヒトーリンを粛正した後、その場にいたアムロと手を組み巨神に立ち向かう。
時系列的には本作の2年後に当たる『逆襲のシャア』と異なり、ストレートの長髪にサングラスという格好をしている。
無限力によれば、ジュドーやアムロと同じく、ユウキ・コスモの生まれ変わりであるという。
カイ・シデン
機動戦士VS伝説巨神 逆襲のギガンティス 登場人物
ジャーナリストで元ホワイトベース乗組員。宇宙世紀0090年のロンド・ベル結成式典に登場したアムロ・レイは影武者であると証言するが、後に撤回する。撤回するまでの間にブライト・ノアが秘密裡に接触し、事情を説明したためとする説が有力らしい。
ヨシユキ・トミノ
小説家。宇宙世紀の歴史小説を著述しているほか、『伝説巨神』などのフィクションも手がけている。
無限力（むげんちから）
巨神の核とでも呼ぶべき存在。この世界を見限る決定を下す。
彼（彼女？）によれば、『伝説巨神イデオン』の世界が滅びた後、150億年の時を経て再び創成されたのが宇宙世紀の世界であり、ニュータイプ能力はかつてのような争いが再び起きないようにと無限力が人類に分け与えた力だという。
木星出身者にニュータイプが多いのは、木星近辺に存在するある種の力場＝無限力の影響によるものとされ、実際にニュータイプであったシャリア・ブルやパプテマス・シロッコの航海記録に「“血まみれの巨神”に出会った」という記述が残されていたことから、アムロに木星圏と「伝説巨神」の調査任務が与えられることとなった。
ジュドーに語りかけるシーンでは、『イデオン』のカララ・アジバやパイパー・ルウの姿がイメージとして現れている。
機動戦士VS伝説巨神 逆襲のギガンティス 登場兵器
MSΖ-009M メガゼータ
プロトタイプΖΖガンダムの改修機。
ジム・スナイパー,EX
メガゼータと共に木星圏に持ち込まれたモビルスーツ。2機存在し、それぞれシマと鉄面皮が搭乗。メガゼータの支援を行うも、巨神の全方位ミサイル斉射に巻き込まれ、中破してしまう。
デコプチ（デコレーション・プチモビルスーツ）
作業用のプチモビルスーツをSD風にデコレーションしたもの。実際に乗る作業員からは不満が挙がっているが、整備士によれば「流行でこれじゃないと売れない」らしい。正確には軍属ではなく、オリュンポス・コロニーの作業用機であり、冒頭でジュドーがガンダムMk-II型のデコプチに乗っている。
作中にはMk-II、ゲルググ、騎士ガンダムをモデルにした機体のほか、一部分のみだが伝説の救世主と共に戦う魔神に酷似した機体が映り込んでいる。
ジュピトリス級資源採掘艦
物語冒頭とラストに登場する。メガゼータとアムロたちを、地球からオリュンポス・コロニーに運んできた。
木星圏部隊
機動戦士VS伝説巨神 逆襲のギガンティス 登場兵器
MS-06 ザクII作中の宇宙世紀0091年ではすでに旧型だが、ネオ・ジオン木星圏部隊では警備や作業を中心に現役使用されている。
MS-10 ペズン・ドワッジザクII同様に旧型だが、ネオ・ジオン木星圏部隊では未だに現役。
MS-R12 リックギガン
MS-16 ドガッシャ
ザクII型デコプチヒトーリンが操縦する。
巨神（伝説巨神、血まみれの巨神）遺跡のような姿で小惑星の表面に埋まっていた巨大兵器。『イデオン』本編よりカラーリングがダークトーンになり、両肩に二連装砲が左右2基ずつ増設されている（作中未使用）。また、全体的に『イデオン』よりも細かいディテールが増えている。
ヒトーリンは木星圏で「掘り出した」と考えていたが、実際には原子を少しずつ結び付け、無から有へと「誕生」しつつある段階だった。自らを破壊しに来たシャアの部隊を圧倒、全方位ミサイルで壊滅状態に追いやる。最終的にジュドーとアムロによってミネバを奪還され、上腕部から光線を発射しようと試みるが、メガゼータとスザクの総攻撃で消滅させられた。
シャア・アズナブル部隊
機動戦士VS伝説巨神 逆襲のギガンティス 登場兵器
AMS-110 キタラ頭部と下腹部から伸びた長い角（下側のものは折り畳むことができる）の先端を結んで体の前方にビームの刃を形成し、体当たりで攻撃する。大型目標を攻撃する際は四肢を真後ろに向けた突撃姿勢に変形する。足は前後に開き、長方形の板のような腕の、手の甲に相当する部分からは細長い槍状の突起が3本突き出している。多数機がシャアのスザクに率いられて木星圏に現れ、ヒトーリン一派の部隊と交戦するが、巨神によって全滅させられる（なお、少なくとも1機はメガゼータに撃破されている）。
スザク（S・ザク・ザクIII改・改）シャアの搭乗するザク系モビルスーツ。スカート部分にビームキャノンを装備している。
本作では後年に制作された配信アニメ『機動戦士ガンダム Twilight AXIS』における設定と異なり、シャアがザクIIIに搭乗している。
MA-08-2 ビグザム改2機登場し、大型メガ粒子砲を巨神に撃つが、バリアーで防がれ、その後両機とも巨神に破壊される。作中では「ビグザム」としか呼ばれず、テロップでビグザム改と紹介されている。
ムサイ級軽巡洋艦ビグザム改を輸送してきた。巨神にビグザム改をぶつけられて撃沈される。
エンドラ級軽巡洋艦
機動戦士VS伝説巨神 逆襲のギガンティス 評価
ロボット作品のクロスオーバーゲーム『スーパーロボット大戦シリーズ』のプロデューサーである寺田貴信は、本作を「クロスオーバーものの教科書」と評している。
「このマンガがすごい！WEB」では、「イデ」「ニュータイプ」という両作品のテーマを「木星」を軸として繋げた長谷川の想像力を評価している。
Transmission Control Protocol
Transmission Control Protocol（トランスミッション コントロール プロトコル、TCP）はIPネットワーク上のアプリ間・コネクション型・高信頼性・ストリーム指向の通信プロトコルである。伝送制御プロトコルとも呼ばれる。
Transmission Control Protocol 概要
TCPは通信プロトコルである。TCPではポート、ソケット、コネクションの概念が導入され、IPネットワークのホスト上にあるアプリケーション同士がコネクションを通じて通信する。確立されたコネクションはTCPが定める制御機構によって到着が保証され、破壊が検出され、流量や輻輳が制御されており、これを通信路としてバイトストリームが伝達される。
TCPを用いることでインターネットにおける到達保証付きアプリケーション間メッセージ通信が可能になるため、ファイル転送、電子メール、World Wide Web、リモート管理など様々なインターネット・アプリケーションで利用される。上位プロトコルにはHTTP、FTP、Telnet、SSHなどがある。
TCPはインターネット・プロトコル・スイートを構成し、Internet Protocolの上位プロトコルとして使われる。またOSI参照モデルに当てはめるならトランスポート層にあたる。その仕様はIETFによりRFC 9293 (STD 7) として標準化されている。なお、IPヘッダでのプロトコル番号は6である。
対比されるプロトコルにUser Datagram Protocol (UDP) がある。UDPは信頼性よりもシンプルさ・低レイテンシを重視したデータグラム通信を提供する。TCPはより信頼性が高くその分オーバーヘッドがある。
Transmission Control Protocol 起源
1974年5月、Institute of Electrical and Electronic Engineers (IEEE) が "A Protocol for Packet Network Interconnection" と題した論文を出版。著者はヴィントン・サーフとロバート・カーンで、ノード間でパケット通信を使い資源を共有するインターネットワーキングのプロトコルを記述したものである。このモデルでの中核制御コンポーネントが Transmission Control Program で、ホスト間のコネクション指向のリンクとデータグラムサービスの両方を含んでいた。当初一体だった Transmission Control Program は後にモジュール化されたアーキテクチャに分割され、コネクション指向部分の Transmission Control Protocol とデータグラムサービス部分の Internet Protocol に分けられた。このモデルを一般に TCP/IP と呼ぶが、公式にはインターネット・プロトコル・スイートと呼ぶようになった。
Transmission Control Protocol 機能
TCPはIPネットワーク上で利用され以下の機能を提供する。これらの機能を実現する機構は#プロトコル操作を参照。
IPはホスト間通信を可能にするが、そのままだとホストへの全信号を1つのアプリケーションのみが受け取る。TCPはポート機能を提供することで、1ホスト内複数アプリケーションへの通信振り分けを可能にする。すなわちアプリケーション間通信を提供する。
IPはパケットの送出を可能にするがパケットの到達を保証しない。TCPは到達確認とデータ再送要求を提供することで、送出されたセグメントが宛先へ到達することを保証する。
IPは独立したパケットを送信するため、パケット間の関係性を扱わない。TCPはバイトストリーム入出力機能を提供することで、実用されるIPパケットサイズを超えた、ファイルやデータストリームの送信を可能にする。
ネットワークの輻輳や負荷分散、その他ネットワークの予測できない振る舞いにより、IPパケットは遅延し順序がばらばらに届きうる。ストリームをパケットに分割して送出しそれを到着順に再構成した場合、元のストリームを復元できる保証がない。TCPは順序制御を提供することで、パケット群からストリームを再構築できることを保証する。
Transmission Control Protocol 機能
IPは疎通の確認なくパケットを送信するため、コネクション（仮想回線）の概念を持たない。TCPはソケット対に基づくコネクションを定義することでコネクション型通信を提供する。ストリーム送信や各種制御はコネクション単位で管理されるため、単一のアプリケーションが複数のコネクション（宛先アプリケーション）を独立して扱えるようになる。
通信先にとって過剰量のデータがコネクションへ流れ込まないよう、TCPは流量制御を提供する。
IPネットワークへ無秩序にパケットが送出されるとネットワークの混雑（輻輳）を引き起こす。TCPはそれらの問題を検出し、ネットワークの混雑が起きにくくなるよう制御して他の問題が発生する可能性を低くする。
Transmission Control Protocol 特性
TCPは高速さよりも完全性に重きを置く（高信頼ストリーム配送サービス）。ゆえにパケットの到達が保証され、データを正しく並べかえることができる。その反面、メッセージの順序がばらばらだったり、喪失したメッセージの再送を待ったりすることがあると、秒のオーダーの比較的長い遅延が生じることがある。よってリアルタイム性を要求されないが、1ビットの誤りも許されないファイル転送などの用途が主である。TCPは完全性よりもリアルタイム性を求められるVoIPなどのアプリケーションには向いていない（多少のパケットの欠損には耐えうるため完全性は多少は緩めても良い）。そのような用途には一般に User Datagram Protocol (UDP) 上の Real-time Transport Protocol (RTP) などのプロトコルが推奨される。
Transmission Control Protocol 利用
TCPの利用例としてWorld Wide Web (WWW)、電子メール、File Transfer Protocol、Secure Shell、ファイル共有、一部のストリーミングが挙げられる。
Transmission Control Protocol TCPセグメント構造
TCPセグメント（英: TCP segment）はTCPにおける送受信単位である。
TCPは上位から受け取ったデータを分割し、それにTCPヘッダを付与してTCPセグメントを作成する。TCPセグメントはさらに Internet Protocol (IP) データグラムにカプセル化される。TCPセグメントは「データを相手と交換するためにTCPが使う情報の束」である。
なお、非公式に「TCPパケット」という用語が使われることがあるが、最近の用法では TCP PDU (Protocol Data Unit) は「セグメント」、IP PDU は「データグラム」、データリンク層のPDUは「フレーム」と呼ぶのが一般的である。
プロセスはTCPを呼び出し、データを格納したバッファを引数で渡すことでデータを送信する。TCPはそれらのバッファ内のデータをセグメント群にパッケージし、インターネット・モジュール（例えばIP）を呼び出すことで宛先のTCPへ各セグメントを送信する。
TCPセグメントは、セグメント・ヘッダとデータ部分から成る。TCPヘッダは10の必須フィールドとオプションの拡張フィールドを含む（テーブルではオプション部分をオレンジで示している）。
Transmission Control Protocol TCPセグメント構造
データ部はヘッダ部の後に続いている。その内容はアプリケーションに渡すべきデータである。データ部の長さはTCPセグメントのヘッダには記されておらず、IPヘッダにあるIPデータグラム長からIPヘッダとTCPヘッダの長さを差し引いて計算できる。
シーケンス番号（32ビット） – 2つの役割がある。
SYNフラグがセットされている場合 (1)、初期シーケンス番号である。実際の先頭データバイトのシーケンス番号と対応する確認応答の確認応答番号は、このシーケンス番号に1を加えた値になる。
SYNフラグがセットされていない場合 (0)、このセッションにおけるこのパケットの先頭データバイトの累積シーケンス番号である。
Transmission Control Protocol TCPセグメント構造
フラグあるいは制御ビット列（9ビット） – 9個の1ビットのフラグがある。
NS（1ビット） – ECN-nonce 輻輳保護（RFC 3540 でヘッダに追加）
CWR（1ビット） – 輻輳制御ウィンドウ縮小 (Congestion Window Reduced)。ECEフラグがセットされたTCPセグメントを受信した際、輻輳制御機構で応答するときにセットする。（RFC 3168 でヘッダに追加）
ECE（1ビット） – ECN-Echo を示す。
SYNフラグがセットされている場合 (1)、ECNを利用可能であることを示す。
SYNフラグがセットされていない場合 (0)、通常送受信時にIPヘッダに Congestion Experienced フラグがセットされたパケットを受信したことを示す。（RFC 3168 でヘッダに追加）
URG（1ビット） – 緊急ポインタ・フィールドが有効であることを示す。
ACK（1ビット） – 確認応答番号フィールドが有効であることを示す。最初のSYNパケットを除く以降の全パケットでこのフラグをセットする。
PSH（1ビット） – プッシュ機能。バッファに蓄えたデータをアプリケーションにプッシュする（押しやる）ことを依頼する。
RST（1ビット） – コネクションをリセットする。
Transmission Control Protocol TCPセグメント構造
SYN（1ビット） – シーケンス番号の同期。通信する両方で最初のパケットだけ、このフラグをセットする。他のフラグはこのフラグの値によって意味が変化したり、このフラグの値によって有効/無効が決まる。
FIN（1ビット） – 送信終了を示す。
Transmission Control Protocol TCPセグメント構造
オプション（0から320ビットまで可変で、32ビット単位で変化する） – ヘッダ長フィールドによって、このフィールドの長さが決まる。個々のオプションは、オプション種別（1バイト）、オプション長（1バイト）、オプションデータ（可変）から成る。オプション種別フィールドはオプションの種類を示し、オプションとしては必ず存在するフィールドである。オプションの種類によって扱い方が違い、後続の2つのフィールドの有無も異なる。存在する場合、オプション長フィールドはそのオプションの全長が格納されており、オプションデータ・フィールドにはオプションに関わる値が格納されている。例えば、オプション種別が 0x01 の場合、No-Op オプションであることを意味し、オプション長やオプションデータは存在しない。オプション種別が0の場合、End Of Options オプションであることを意味し、この場合も1バイトだけである。オプション種別が 0x02 の場合、最大セグメントサイズ (MSS) オプションであることを意味し、その後ろに1バイトのMSSフィールド長を指定するフィールドがある（値は 0x04）。この長さはオプションの全長であるため、オプション種別フィールドとオプション長フィールドのぶんも含んでいる。従って、MSS値は通常2バイトで表され、オプション長は4（バイト）となる。例えば、MSS値が 0x05B4 なら、MSSオプション全体の値は (0x02 0x04 0x05B4) となる。
一部のオプションはSYNがセットされているときだけ送信される。それらは以下で [SYN] で示している。各行の先頭は「オプション種別[, オプション長, オプション値]（全ビット数）」の形式で示す。
0（8ビット） - オプションリストの終了
1（8ビット） - 何もしない（NOP、パディング）。オプション・フィールドを32ビット境界に揃えるのに使う。
2,4,SS（32ビット） - 最大セグメント長（最大セグメントサイズ を参照） [SYN]
3,3,S（24ビット） - ウィンドウスケール（詳しくはウィンドウスケーリング参照）[SYN]
4,2（16ビット） - 選択確認応答が可能。[SYN] （選択確認応答を参照）
5,N,BBBB,EEEE,...（可変長、N は 10, 18, 26, 34 のいずれか） - 選択確認応答 (SACK)。最初の2バイトの後に選択確認応答される1から4ブロックのリストを32ビットの開始/終了ポインタで示す。
8,10,TTTT,EEEE（80ビット） - タイムスタンプと前のタイムスタンプのエコー（TCPタイムスタンプを参照）
14,3,S（24ビット） - チェックサム方式変更要求。[SYN]
15,N,...（可変長） - チェックサム方式が変更されて、そのチェックサムが16ビットより長い場合にこれでチェックサム値を示す。
他のオプションは既に使われていないもの、実験的なもの、標準になっていないものなどである。
Transmission Control Protocol プロトコル操作
TCPプロトコル操作は3つのフェーズに分けられる。コネクションは多段階のハンドシェイクプロセスで正しく確立する必要があり（コネクション確立フェーズ）、その後「データ転送フェーズ」に入る。データ転送が完了したら「コネクション終了フェーズ」で仮想回線を閉じ、確保していたリソースを解放する。
TCPコネクションはオペレーティングシステムがソケットというプログラミングインタフェースを通して管理する。TCPコネクションが存在する間、以下のような状態間で遷移する。
コネクションを確立する際、TCPでは3ウェイ・ハンドシェイクを行う。
クライアントがサーバと接続する前、サーバはコネクション可能なようにポートをバインドしておかなければならない。これをパッシブ・オープンと呼ぶ。サーバ側がパッシブ・オープンになっていれば、クライアントはアクティブ・オープンを開始できる。コネクションを確立するための3ウェイ・ハンドシェイクは次のようになる。
この時点でクライアントとサーバ双方がコネクション確立の確認応答を受け取ったことになる。
Transmission Control Protocol プロトコル操作
多くの実装では、テーブルの1エントリを動作中のOSプロセスとのセッションにマッピングする。TCPセグメントにはセッション識別子がないため、通信している双方でクライアントのアドレスとポートでセッションを識別する。パケットを受信すると、TCPソフトウェアはそのテーブルを参照して、対応するプロセスを見つける。
サーバ側でのセッション数はメモリ容量にのみ制限され、コネクション確立要求がくるたびに増えていく。しかし、クライアントはサーバに最初のSYNセグメントを送る前に無作為にポートを選んで確保しなければならない。このポートはコネクションをクローズするまで確保され続け、実質的にクライアントの持つIPアドレス毎の外に出て行くコネクション数を制限している。アプリケーションが不要になったコネクションをクローズしそこねると、空いているポートが足りなくなり、新たなTCPコネクションを確立できなくなる。
また、通信する双方で確認応答を受け取っていない送信済みデータとアプリケーションに渡す前の受信データを格納しておく領域を確保する必要がある。
TCPが提供する機能（#機能を参照）は以下の機構で提供される。
Transmission Control Protocol プロトコル操作
TCPは「シーケンス番号」を使ってデータの各バイトを識別する。シーケンス番号は双方のホストが送信するバイト列に先頭から振られる番号であり、それによってデータがどう分割されても、順番が入れ替わっても、転送中に失われても、元のデータを復元できる。ペイロードの各バイトを送るたびにシーケンス番号をインクリメントしなければならない。3ウェイ・ハンドシェイクの最初の2ステップで、双方のホストは初期シーケンス番号 (ISN) をやりとりする。この番号は任意であり、TCPシーケンス番号予測攻撃への防御のために予測不可能な値とすべきである。
Transmission Control Protocol プロトコル操作
TCPは「累積確認応答」方式を採用しており、受信側が確認応答を返すとき、そのセグメントで示されている確認応答番号は、対応するシーケンス番号未満のデータを全て受信済みであることを示している。送信側はペイロードの先頭バイトのシーケンス番号をそのセグメントのシーケンス番号として設定する。受信側は次に受信することを期待しているバイトのシーケンス番号を確認応答番号に設定して確認応答を返す。例えば、送信側が4バイトのペイロードをシーケンス番号 100 で送信する場合、そのペイロードの4バイトのシーケンス番号は順に 100、101、102、103 である。受信側がこのセグメントを受信すると、その確認応答での確認応答番号は 104 となり、次のパケットで送られてくるペイロードの先頭バイトのシーケンス番号となっている。
累積確認応答に加えて、受信側は選択確認応答でさらなる情報を送ることができる。
送信側がネットワーク内でデータが失われたと判断した場合、データの再送を行う。
後述の#チェックサムの計算も参照。
シーケンス番号と確認応答は、パケットの重複、喪失パケットの再送、データの順序通りの並べ替えなどを扱っている。受信したパケットの内容が正しいことを確認するため、TCPにはチェックサムフィールドがある。チェックサムフィールドは設定必須の項目であり省略できない。
Transmission Control Protocol プロトコル操作
TCPチェックサムは、現在の標準から見れば弱い。データリンク層のビット誤り率が高ければ、TCPチェックサムとは別の誤り検出訂正機能が必要である。TCP/IPの下層であるデータリンク層には一般にCRCなどのもっと強力な検査機構があり、TCPチェックサムの弱さを一部補っている（例えば、PPPやイーサネット）。しかし、だからといって16ビットのTCPチェックサムが無駄というわけではない。実際、CRCで保護された通信路でパケットに誤りが残ることはよくあるが、エンドツーエンドの16ビットTCPチェックサムがそういった単純な誤りを捉えている。これはエンドツーエンド原理が機能している例である。
TCPはエンドツーエンドのフロー制御プロトコルを使い、送信ペースが受信側にとって速すぎる状態になるのを防いでいる。様々な性能の機器が接続されたネットワークでは、フロー制御は欠かせない機構である。例えば、PCから性能の劣るPDAにデータを送る場合、PDAの性能に合わせて送信ペースを調整する必要がある。
Transmission Control Protocol プロトコル操作
TCPはスライディングウィンドウによるフロー制御を採用している。各TCPセグメントについて、受信側は「ウィンドウサイズ」フィールドで、そのコネクション用のバッファの空き容量に相当する今後受信可能なデータの量（バイト単位）を示す。送信側は確認応答を待ち合わせるまでに、そのフィールドで指定された量までのデータを送り、新たな確認応答でウィンドウサイズ・フィールドを確認してさらに送信できるデータ量を更新する。
受信側がウィンドウサイズを0としたとき、送信側は送信を停止してタイマ (persist timer) を起動する。このタイマは受信側のウィンドウサイズの更新セグメントが喪失してデッドロック状態になるのを防ぐためのものである（受信側がウィンドウサイズを更新しないと送信を再開できないため）。タイマがタイムアウトすると、送信側は小さなパケットを送り、その確認応答で受信側のウィンドウサイズが回復したかを調べる。
Transmission Control Protocol プロトコル操作
受信側での受信データの処理が遅いと、ウィンドウサイズの指定は小さいままとなる。これをSilly Window Syndrome (SWS)と呼び、送信側は1度に数バイトのデータしか送れなくなり、TCPヘッダの方が大きな割合を占めるため転送効率が極端に低下する。そのような状況に陥らないようにするためのウィンドウ・アルゴリズムが RFC 813 (Window and acknowledgement strategy in TCP) に記載されている。
TCPは高性能を達成し輻輳崩壊（ネットワーク性能が数桁のオーダーで低下する現象）を防ぐため、輻輳制御機構をいくつか備えている。ネットワークに流入させるデータレートを制御し、崩壊のきっかけとなるようなレート未満でデータを送るよう保つ。また、おおまかに最大最小公平なフロー割り当てを目指す。
送信データへの ACK (確認応答)の有無は、送信側でネットワークの状態を推測する材料となる。これをタイマと組み合わせ、データのフローの振る舞いを変化させることができる。これを一般に輻輳制御またはネットワーク輻輳回避などと呼ぶ。
最近のTCP実装では、スロースタート、輻輳回避、TCP高速再送アルゴリズム、ファストリカバリ(en, RFC 5681) という4つの相互にからみあったアルゴリズムを使用している。
Transmission Control Protocol プロトコル操作
スループットをあげるため輻輳しない限界まで送信側はスライディングウィンドウを大きくする必要があるが、ウィンドウサイズを調整する輻輳回避アルゴリズムは長年研究されている。一覧は w:TCP congestion avoidance algorithm を参照。かつては、輻輳するとパケットロスが発生することを利用し、パケットロスをベースにした TCP Reno およびそれを改良した TCP NewReno (RFC 3782) がよく使われていたが、現在では、送信側のスライディングウィンドウにどれだけの時間とどまっていたかを元にしたアルゴリズム (Delay-based Congestion Avoidance) が中心になっており、Microsoft Windows では、Windows Vista 以降は、Compound TCP が採用され、Linux では 2.6.8〜2.6.18 は BIC TCP が、2.6.19 以降は CUBIC TCP が使われている。
Transmission Control Protocol プロトコル操作
さらに送信側には「再送タイムアウト (RTO)」があり、送信してから確認応答が戻るまでの時間であるラウンドトリップタイム (RTT) を推算し、ばらつきも考慮して設定する。このタイマの動作は RFC 2988 で規定されている。RTTの推算には微妙な点がある。例えば、再送パケットのRTTを計算する場合は注意しなければならず、一般にカーンのアルゴリズムやTCPタイムスタンプ（RFC 1323 参照）を使う。個々のRTTの標本から時系列で平均をとり、ジェイコブソンのアルゴリズムを使って Smoothed Round Trip Time (SRTT) を生成する。最終的にSRTT値がRTTの推算に使われる。
TCPを拡張して、喪失を高信頼に扱ったり、誤りを最小化したり、輻輳を制御してより高速化しようという試みが今も行われている。
最大セグメントサイズ以下の小さなパケットをばらばらと送るのは非効率なので、送信を遅延し、それらを1つのTCPパケットにまとめるのが、Nagleアルゴリズムである。同様に、複数のACKを1つにまとめるのが、TCP遅延ACKである。どちらも、送信を遅延させるという点においては同じだが、相互に影響し合い、遅延が増大するという問題があり、詳細はNagleアルゴリズムを参照。
Transmission Control Protocol プロトコル操作
最大セグメントサイズ (MSS) はバイト単位で指定され、単一のセグメントとして受信可能な最大データ量を示す。性能を最大限発揮するにはIPフラグメンテーションを十分防げる程度に小さくする必要がある。IPフラグメンテーションが行われると、パケット喪失時の再送に時間がかかることになる。一般にコネクション確立時にMSSオプションを使って双方のMSSを通知するので、適切なMSSを決めるにはデータリンク層の Maximum Transmission Unit (MTU) から導出したMSSを通知すればよい。さらに送信側は経路MTU探索を使うことができ、通信相手との間にある経路でMTUが最小の部分を推定し、それを使ってMSSを動的に調整しIPフラグメンテーションを防ぐことができる。
MSS通知は「MSSネゴシエーション」とも呼ばれる。ネゴシエーションというと送信側と受信側が交渉して合意に達するかのように思われるが、実際には異なり、送信する方向によってそれぞれ異なるMSSが設定可能である。これは例えば一方がメモリ容量が小さいため、バッファ領域を大きくとれない場合などに起きる（発見したパスMTUより小さいこともありうる）。
Transmission Control Protocol プロトコル操作
もともとのTCPプロトコルで採用されている累積確認応答方式を使うと、パケットを喪失したときに非効率になる可能性がある。例えば、10,000バイトのデータを10個のTCPセグメントで送信し、その最初のパケットが喪失したとする。もともとの累積確認応答プロトコルでは、受信側は1,000から9,999までのバイトは受信成功、ただし0から999までのバイトを含む先頭パケットの受信に失敗したという風に伝えることができないので、送信側は10,000バイト全体を再送しなければならない。
このため RFC 2018 で「選択確認応答 (SACK)」オプションが追加された。これは、通常の累積確認応答とは別に、受信側が不連続なブロックを正しく受信したという確認応答を返せるようにしたものである。選択確認応答にはオプション部分にいくつかのSACKブロックを指定し、SACKブロックには正しく受信できた連続な範囲のシーケンス番号の開始点と終了点を指定する。例えば、先ほどの例では 1000 と 9999 のシーケンス番号をSACKオプションで示せばよい。すると送信側は 0 から 999 までのバイトを含む最初のパケットだけを再送する。
Transmission Control Protocol プロトコル操作
SACKオプションの拡張として RFC 2883 で定義されたデュプリケートSACK (D-SACK) オプションがある。パケットの順序がばらばらになると、送信側への確認応答も順序どおりにならないため送信側でパケット喪失と勘違いし、喪失したと思われるパケットを再送することがあり、同時にネットワーク輻輳を防ぐため送信ペースを落とす。このとき、受信側が D-SACK オプションで再送パケットが重複していることを通知すれば、遅くなっていた送信ペースを元に戻すことができる。
SACKオプションは必須ではなく、両者がサポートしている場合だけ使われる。これはコネクション確立時に調整される。SACKオプションは主なTCPスタックでサポートされており、広く使われている。選択確認応答は Stream Control Transmission Protocol (SCTP) でも使われている。
広帯域ネットワークをより効率的に使うには、TCPウィンドウのサイズを大きくする必要がある。TCPヘッダのウィンドウサイズのフィールドは16ビットで、2バイトから65,535バイトまでしか設定できない。
Transmission Control Protocol プロトコル操作
ウィンドウサイズ・フィールドは拡張できないので、スケールファクタが導入されている。RFC 7323 で定義されているウィンドウスケール・オプションを使えば、最大ウィンドウサイズを 65,535 バイトから 1 ギガバイトに拡張できる。ウィンドウサイズのスケールアップはTCPのチューニング (en) に必須の要素である。
ウィンドウスケール・オプションは3ウェイ・ハンドシェイクの際にしか使われない。ウィンドウスケール・オプションのオプション値は、16ビットのウィンドウサイズ・フィールドの値を左にシフトするビット数を表している。ウィンドウスケールの値は0（シフトしない）から14まで指定でき、通信の双方向で別々に設定できる。どちらの方向もSYNセグメントのオプションとして通知する。
一部のルーターやファイアウォールは、このスケールファクタを転送時に書き換えることがある。すると送信側と受信側でウィンドウサイズの認識が異なることになり、トラフィックが不安定になって、非常に低速になることがある。