stanford-oval/wikipedia huggingface dataset:
ペンザンスヘリポート

ペンザンスヘリポート（英語: Penzance Heliport）は、コーンウォールのペンザンスから北東1.1kmに位置しているヘリポート。シリー諸島への定期便が運航され、シャトルバスでペンザンス駅に接続される。最初のヘリポートは2012年10月31日に閉鎖され、後に新しいヘリポートが建設された。ペンザンス・ヘリコプターがスローン・ヘリコプターと提携して運航するトレスコ島とセント・メアリーズ島へのヘリコプター路線の拠点となっている。
歴史

1937年にゴルフ場から複葉機デ・ハビランド DH.84 ドラゴン（英語版）（後にDH.89 ドラゴン・ラピードで更新）による路線が開設されていたが、1964年5月1日BEAヘリコプター（英語版）がランズ・エンド空港とシリー諸島の間でシコルスキー S-61を使用して最初の運航サービスを開始した。この路線は、9月1日にペンザンスヘリポートへ移転した。ヘリポートの建設費は88,000ポンド、この金額は2023年時点の£2,300,000と同等である。開設当初は、北緯50度07分41秒 西経005度31分06秒﻿ / ﻿北緯50.12806度 西経5.51833度﻿ / 50.12806; -5.51833に位置し、08/26方向の373 x 45mの芝生の滑走路内側に、30m四方のコンクリート製のヘリパッド1つを有していた。
1964年9月1日、ペンザンス市長のアルフレッド・ベッカーレグ市長夫妻によって正式にヘリポートは開設された。
2012年10月31日、ブリティッシュ・インターナショナル・ヘリコプターズは、乗客数の減少と運航にかかる高額費用のため運航を停止した。同社は、ヘリポートをセインズベリーに売却し 、資金を調達するためにコーンウォール西部の別の地に移転する予定であると発表したが、運航を継続するのに適した代替地は確保できなかった。跡地は2013年4月上旬にメインターミナルビルの解体工事が始まり、後にセインズベリーの店舗となっている。
新しいヘリポート

2016年に、ペンザンスとシリー諸島のセント・メアリーズ島とトレスコ島を結ぶ新しいヘリコプター路線の開設計画が発表された。提案には、ペンザンスのジェルバート・ウェイ（以前のヘリポートの付近）に新しいヘリポートを建設することが含まれた。計画申請書は、コーンウォール評議会が計画申請書に対してこれまで与えたことがないほどの、最高レベルの支持を受けた。
2017年2月、新しいヘリポート計画への最初の承認は、コーンウォール評議会の戦略計画委員会によって全会一致で与えられた。この決定は、後に司法審査でシリー諸島蒸気船会社によって異議を申し立てられた。司法審査に対する反対請願は11,000以上の署名を獲得し 、修正された計画申請書が提出された。修正された申請書は、2018年8月にコーンウォール評議会によって2回目の全会一致の決定で承認された。新しいヘリポートは2018年から2019年にかけて建設、2020年3月に運航が開始され、セント・メアリーズ島とトレスコ島への路線が運用されている。
小柳津

小柳津（おやいづ）
地名 > 町・字

小柳津 (焼津市) - 静岡県焼津市小柳津
姓

日本人の姓のひとつ。
小柳津林太郎 - 実業家。
小柳津真由美 - フリーアナウンサー。
小柳津要人 - 実業家、武士。丸善専務取締役社長。
小栁津徹也 - YouTuber 東海オンエアのリーダー
小柳津政雄 - 陸軍軍人。最終階級は陸軍中将。
ほか
セルゲイ・グレンコ

セルゲイ・グレンコ（Sergei Gurenko、発音 [sʲarˈɣʲɛj vʲiˈtalʲɛvʲitʂ ɣuˈrɛnka]、1972年9月30日 - ）は、ソビエト連邦・フロドナ出身の元ベラルーシ代表サッカー選手であり現サッカー指導者。ポジションはディフェンダーまたはミッドフィールダー。
経歴 > クラブ

1989シーズン、地元クラブFCネマン・フロドナにてプロサッカーキャリアをスタートさせた。翌1990シーズンから同クラブの不動のレギュラーとして活躍し、評価を高めていった。
1995年、ロシアのFCロコモティフ・モスクワに移籍した。ロコモティフ・モスクワでは、グレンコの能力、技術の高さ、そして闘志むき出しのプレーですぐにチームのリーダー的存在となった。1999年、より高りレベルでのプレーを求めたグレンコは、当時世界トップリーグだったイタリアのASローマに加入した。しかし、ローマでは成果を残すことができず、1シーズン目はリーグ戦わずか7試合の出場に終わった。
2000-01シーズン、出場機会を求めてラ・リーガのレアル・サラゴサへとレンタル移籍をした。イタリアと比べるとわずかながら劣るリーグではあったものの、ここでも定位置確保には至らず、翌年にパルマへと活躍の場を移した。パルマでも失敗に終わったが、翌シーズンに移籍したピアチェンツァ・カルチョではレギュラーとして活躍した。
2003年、ロコモティフ・モスクワに復帰した。ここでは以前在籍していた時同様にスタメンを勝ち取り、2年目からはチームの副キャプテンに任命された。3年目には中心選手としてロシア・プレミアリーグ制覇に貢献。充実したシーズンを送った。
2008年12月8日、母国のFCディナモ・ミンスクに移籍した。約1年後の2009年8月21日、現役を引退した。
経歴 > 代表

1994年5月5日、ウクライナ代表戦でベラルーシ代表デビュー。以降10年近くを代表キャプテンとしてまとめたが、メジャー大会出場は叶わなかった。代表通算出場80試合はベラルーシ代表史上2番目の記録である。また、1999年にはベラルーシ年間最優秀選手に選出されている。
個人成績

| # | 日付 | 会場 | 対戦国 | 得点 | 結果 | 大会 |
| --- | --- | --- | --- | --- | --- | --- |

| 1 | 1997年8月20日 | ディナモ・スタディオン, ベラルーシ |  スウェーデン | 1 – 0 | 1–2 | 1998 FIFAワールドカップ予選 |
| 2 | 1998年10月14日 | ニニアン・パーク, カーディフ, ウェールズ |  ウェールズ | 1 – 1 | 2–3 | EURO2000予選 |
| 3 | 2003年3月29日 | ディナモ・スタディオン, ベラルーシ |  モルドバ | 2 – 1 | 2–1 | EURO2004予選 |
タイトル

ベラルーシ・カップ : 1回
1992-93
ロシア・プレミアリーグ : 1回
2004
ロシア・カップ : 3回
1995-96, 1996-97, 2006-07
コパ・デル・レイ : 1回
2000-01
コッパ・イタリア : 1回
2001-02
アマンドラ

アマンドラ（伊: Amandola）は、イタリア共和国マルケ州フェルモ県にある、人口約3,300人の基礎自治体（コムーネ）。
地理 > 位置・広がり

フェルモ県のコムーネ。県都フェルモから南西へ36kmの距離にある。
地理 > 位置・広がり > 隣接コムーネ

隣接するコムーネは以下の通り。括弧内のAPはアスコリ・ピチェーノ県、MCはMCはマチェラータ県所属を示す。
コムナンツァ (AP)
グアルド (MC)
モンテ・サン・マルティーノ (MC)
モンテファルコーネ・アッペンニーノ
モンテフォルティーノ
ペンナ・サン・ジョヴァンニ (MC)
サルナーノ (MC)
ズメリッロ
地理 > 気候分類・地震分類

アマンドラにおけるイタリアの気候分類 (it) および度日は、zona E, 2283 GGである。
また、イタリアの地震リスク階級 (it) では、zona 2 (sismicità media) に分類される。
歴史

2009年、アスコリ・ピチェーノ県北部が分割されてフェルモ県が設置された際に、フェルモ県所属となった。
行政 > 分離集落

アマンドラには、以下の分離集落（フラツィオーネ）がある。
Bore, Botundoli, Buzzaccheri, Caccianebbia, Campo di Masci, Capovalle, Casa Coletta, Corazza, Casa di Carlo, Casa Innamorati, Casalicchio, Casa Paradisi Inferiore, Casa Paradisi Superiore, Casa Tasso, Cese, Ciaraglia, Colle San Fortunato, Colle Turano, Coriconi, Corvellari, Cucchiaroni, Fossacieca, Francalancia, Garulla Inferiore, Garulla Superiore, Le Piane, Marnacchia, Merli, Moglietta, Montane, Paolucci, Paterno, Pucci, Rustici, Salvi, San Cristoforo, San Ruffino, Schiti, Scagnoli, Suitullo, Taccarelli, Vena, Verri, Vesciano, Vidoni, Villa Conti, Villa Fiorentina
ブルーフロウ

| --- | --- |
: この項目では、コンピュータゲームについて説明しています。chiharu mkのアルバム"blue flow"については「chiharu mk」をご覧ください。
| --- | --- |
ジャンル:  リアルタイムシナリオシミュレーション
対応機種:  Windows 98 SE/Me/2000/XP
開発元:  工画堂スタジオ・いるかさんちーむ
発売元:  工画堂スタジオ
人数:  1人
メディア:  DVD-ROM
発売日:  2005年3月4日
対象年齢:  制限なし（未審査）
テンプレートを表示
『ブルーフロウ』（Blue Flow）は2005年3月4日に工画堂スタジオから発売されたWindows用リアルタイムシナリオシミュレーションゲーム。同年6月24日には、追加ミッションなどを収録した『ブルーフロウ ファンディスク』が発売された。続編としてブルーブラスターがある。
概要

工画堂スタジオには、戦術シミュレーションゲームとして同社の看板タイトルとも言えるうさぎさんチームの『パワードール』シリーズがあるが、その流れを汲みつつもとっつきやすい作品となることを目指して制作された作品である。
パワードールでは、例えば女性ばかりのキャラクターが登場し性格付けなどの設定も存在するが、一般的なノベルタイプの美少女ゲームのように本編中で彼女たちのストーリーが展開することはほとんどなく、あくまでもシミュレーションゲームとしての"遊べる部分"に特化した作りとなっていた。これは一方で、ユーザーによる、各キャラクターの設定を基にした創作活動が盛んとなる一因ともなっていた。しかしながら、このようなコンセプトで制作されていたことは特にシミュレーションゲームを得意としないゲームユーザーにとって、パワードールシリーズに対してのハードルが高くなってしまう要因ともなっており、それを解消してより広いユーザーに探求することを考え、ブルーフロウが企画された。
このようなコンセプトを実現するための方策として、登場する各キャラクターによるドラマ性の高いシナリオとそれに伴うノベルパートの採用、多数のイベント絵、シミュレーションパートでの操作性の改善やシミュレーションゲームを苦手とするユーザーを念頭に置いた難易度設定などが盛り込まれた。これらの考え方は続編となるブルーブラスターにおいても、改良の上継承された。
しかしながら、パワードールシリーズに対してのハードルを下げる考えで制作された本作においても、シミュレーションパートは決して簡単なものではなく、このようなゲームを苦手とするユーザーにとっては少々手強いものとなっている。また、パワードールシリーズの流れを汲んではいるが、『羅刹2』に近いシステムであると指摘するメディアもある。
ストーリー

惑星ネクタルに住むユアンは友人のジョーカー、黒帯と共に地球軍の輸送機が墜落するのを偶然目撃する。生存者を救出するため墜落地点に向かった彼らは、地球軍が開発した新型機ブルーフロウの存在を知ると共に輸送機を撃墜した惑星連合軍のパワーローダーに囲まれてしまう。
ユアンはこの危機を乗り切るために、ブルーフロウに乗り込む。
ブルーフロウ ファンディスク

| --- | --- |
ジャンル:  リアルタイムシナリオシミュレーション
対応機種:  Windows 98 SE/Me/2000/XP
開発元:  工画堂スタジオ・いるかさんちーむ
発売元:  工画堂スタジオ
人数:  1人
メディア:  DVD-ROM1枚 音楽CD1枚
発売日:  2005年6月24日
テンプレートを表示
ブルーフロウ ファンディスクは2005年6月24日に工画堂スタジオ・いるかさんちーむから発売された『ブルーフロウ』のファンディスク。
ブルーフロウのエンディング後を語った追加ミッションの『プルーフロウEXTRA』、サイドエピソードやエンディング後の想いを主要キャラ3人が綴ったサウンドドラマ、デスクトップアクセサリー、アートワークコレクション、などで構成される。
関連CD

Blue Flow sound collection（KDCA-0036 2005年4月27日発売）
XB-38 (航空機)

XB-38
用途：爆撃機
製造者： ボーイング/ベガ（ロッキード）
運用者： アメリカ陸軍（航空軍）
初飛行：1943年5月19日
生産数：1機
運用状況：試作のみ
表示
XB-38は、アメリカ合衆国のボーイング社製B-17を基にベガ社が改造した機体である。試作のみで量産には至らなかった。
概要

量産されているB-17の搭載するR-1820空冷エンジンが不足した場合に備え、代用エンジンとしてV-1710-89液冷エンジンに換装する試作改造がB-17量産を担当していたベガ社で行なわれ、B-17E一機が改造された。
機体は1943年5月19日初飛行し、テストが進められたが、同年6月16日の9回目のテスト飛行で第3エンジンが発火して試作機が墜落、そのまま計画中止になった。当初予想したR-1820が不足する事がなかったどころか代用のV-1710自体がP-38、P-39、P-40などといった戦闘機に必要とされたので、B-17の代用とする事が出来なくなったためであった。
スペック

全長：22.7 m
全幅：31.6 m
全高：5.8 m
翼面積：141.9 m2
空虚重量：24,900 kg
全備重量：28,183 kg
最大離陸重量：29,000 kg
翼面荷重量：231 kg/m2
発動機：アリソン V-1710-89 (TC付) 液冷V型12気筒(1,425hp) 4基
出力荷重比：0.0655 hp/lb
最大速度：526 km/h
巡航速度：364 km/h
航続距離：3,100 km
実用上昇限度：11,200 m
乗員：10名
武装
ブローニング M2 12.7mm 機関銃 13丁
爆弾2,700 kg
いわしん

いわしん
いわき信用組合
磐田信用金庫
岩国信用金庫（現：西中国信用金庫）
アダム・ブライト

| 基本情報 |
| --- | --- |
国籍:   オーストラリア
出身地:  ビクトリア州メルボルン
生年月日:   (1984-08-11) 1984年8月11日（40歳）
身長 体重:  5' 11" ＝約180.3 cm 175 lb ＝約79.4 kg
選手情報
投球・打席:  左投左打
ポジション:  投手
プロ入り:  2002年
経歴（括弧内はプロチーム在籍年度）
  リミニ・ベースボールクラブ (2010)  読売ジャイアンツ (2011)  メルボルン・エイシズ (2012 - 2013)
 派遣歴
  メルボルン・エイシズ (2010)
国際大会
代表チーム:  オーストラリア
WBC:  2006年、2009年、2013年
 この表について  この表はテンプレートを用いて表示しています。編集方法はTemplate:Infobox baseball playerを参照してください。 ■プロジェクト:野球選手  ■テンプレート  
アダム・ジェームズ・ブライト（Adam James Bright, 1984年8月11日 - ）は、オーストラリア連邦ビクトリア州メルボルン出身の元プロ野球選手（投手）。左投左打。NPBでは育成選手であった。
経歴 > プロ入りとロッキーズ傘下時代

2002年に、17歳でMLBのコロラド・ロッキーズと契約を結んだ。
2006年開幕前の3月には、この年から開催される事となった第1回ワールド・ベースボール・クラシック（WBC）のオーストラリア代表に選出された。
2007年には左のセットアッパーとして、AA級タルサ・ドリラーズで52試合に登板。オフの11月には、「日豪親善 野球日本代表最終強化試合」のオーストラリア代表に選出された。
2009年開幕前の3月に、第2回WBCのオーストラリア代表に2大会連続で選出された。この年はAA級タルサで36試合に登板して、1勝2敗1セーブ7ホールド、防御率4.30の成績を残したが、オフの11月9日にフリーエージェント（FA）となった。
経歴 > イタリア球界時代

2010年6月に、イタリアンベースボールリーグのリミニ・ベースボールクラブと契約を結んだ。オフには、母国オーストラリアのオーストラリアン・ベースボールリーグ（ABL）のメルボルン・エイシズでプレーした。
経歴 > 巨人時代

2010年12月24日に読売ジャイアンツと育成契約を結んだ。
2011年は育成選手として支配下登録選手への昇格を目指していたが、4月30日に登録を見送ることが球団から表明された。「26歳以上の新外国人育成選手の支配下登録は4月末まで」という協約があるため、2011年中の支配下登録の可能性は無くなった。球団代表の清武英利は実力面や肩の故障を見送りの理由に挙げている。肩の回復具合によっては翌2012年シーズンの契約を結ぶことも示唆されていたが、10月22日に球団から戦力外通告を受けた。
経歴 > 巨人退団後

2012年は、秋まではいずれの球団にも所属せず、冬季はABLのメルボルン・エイシズでプレーした。
2013年は、開幕前に開催された第3回WBCのオーストラリア代表に3大会連続で選出された。この年の冬季もメルボルン・エイシズでプレーし、この年を最後に現役を引退した。
プレースタイル・人物

サイドスローに近いフォームから140km/h前後のストレートとスライダーを武器にする。
詳細情報 > 年度別投手成績

一軍公式戦出場なし
詳細情報 > 背番号

022 （2011年）
詳細情報 > 代表歴

2006 ワールド・ベースボール・クラシック・オーストラリア代表
2009 ワールド・ベースボール・クラシック・オーストラリア代表
2013 ワールド・ベースボール・クラシック・オーストラリア代表
Transmission Control Protocol

Transmission Control Protocol（トランスミッション コントロール プロトコル、TCP）はIPネットワーク上のアプリ間・コネクション型・高信頼性・ストリーム指向の通信プロトコルである。伝送制御プロトコルとも呼ばれる。
概要

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はより信頼性が高くその分オーバーヘッドがある。
起源

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 と呼ぶが、公式にはインターネット・プロトコル・スイートと呼ぶようになった。
機能

TCPはIPネットワーク上で利用され以下の機能を提供する。これらの機能を実現する機構は#プロトコル操作を参照。
機能 > アプリケーション間通信

IPはホスト間通信を可能にするが、そのままだとホストへの全信号を1つのアプリケーションのみが受け取る。TCPはポート機能を提供することで、1ホスト内複数アプリケーションへの通信振り分けを可能にする。すなわちアプリケーション間通信を提供する。
機能 > 到達保証

IPはパケットの送出を可能にするがパケットの到達を保証しない。TCPは到達確認とデータ再送要求を提供することで、送出されたセグメントが宛先へ到達することを保証する。
機能 > ストリーム送信

IPは独立したパケットを送信するため、パケット間の関係性を扱わない。TCPはバイトストリーム入出力機能を提供することで、実用されるIPパケットサイズを超えた、ファイルやデータストリームの送信を可能にする。
機能 > ストリーム送信 > 順序制御

ネットワークの輻輳や負荷分散、その他ネットワークの予測できない振る舞いにより、IPパケットは遅延し順序がばらばらに届きうる。ストリームをパケットに分割して送出しそれを到着順に再構成した場合、元のストリームを復元できる保証がない。TCPは順序制御を提供することで、パケット群からストリームを再構築できることを保証する。
機能 > コネクション型通信

IPは疎通の確認なくパケットを送信するため、コネクション（仮想回線）の概念を持たない。TCPはソケット対に基づくコネクションを定義することでコネクション型通信を提供する。ストリーム送信や各種制御はコネクション単位で管理されるため、単一のアプリケーションが複数のコネクション（宛先アプリケーション）を独立して扱えるようになる。
機能 > コネクション型通信 > 流量制御

通信先にとって過剰量のデータがコネクションへ流れ込まないよう、TCPは流量制御を提供する。
機能 > コネクション型通信 > 輻輳制御

IPネットワークへ無秩序にパケットが送出されるとネットワークの混雑（輻輳）を引き起こす。TCPはそれらの問題を検出し、ネットワークの混雑が起きにくくなるよう制御して他の問題が発生する可能性を低くする。
特性

TCPは高速さよりも完全性に重きを置く（高信頼ストリーム配送サービス）。ゆえにパケットの到達が保証され、データを正しく並べかえることができる。その反面、メッセージの順序がばらばらだったり、喪失したメッセージの再送を待ったりすることがあると、秒のオーダーの比較的長い遅延が生じることがある。よってリアルタイム性を要求されないが、1ビットの誤りも許されないファイル転送などの用途が主である。TCPは完全性よりもリアルタイム性を求められるVoIPなどのアプリケーションには向いていない（多少のパケットの欠損には耐えうるため完全性は多少は緩めても良い）。そのような用途には一般に User Datagram Protocol (UDP) 上の Real-time Transport Protocol (RTP) などのプロトコルが推奨される。
利用

TCPの利用例としてWorld Wide Web (WWW)、電子メール、File Transfer Protocol、Secure Shell、ファイル共有、一部のストリーミングが挙げられる。
プロトコル操作

TCPプロトコル操作は3つのフェーズに分けられる。コネクションは多段階のハンドシェイクプロセスで正しく確立する必要があり（コネクション確立フェーズ）、その後「データ転送フェーズ」に入る。データ転送が完了したら「コネクション終了フェーズ」で仮想回線を閉じ、確保していたリソースを解放する。
TCPコネクションはオペレーティングシステムがソケットというプログラミングインタフェースを通して管理する。TCPコネクションが存在する間、以下のような状態間で遷移する。
LISTENING : サーバの場合、任意のリモートクライアントからのコネクション要求を待ち受ける。
SYN-SENT : SYNフラグとACKフラグをセットしたTCPセグメントを相手側が送ってくるのを待つ状態（通常、クライアント側）。
SYN-RECEIVED : コネクション確立要求に対して確認応答を返した後、相手側が確認応答を返してくるのを待つ状態（通常、サーバ側）。
ESTABLISHED : 相手側とコネクションが確立し、指定ポートでのデータの送受信が可能な状態。
FIN-WAIT-1 : FINフラグをセットしたTCPセグメントを先に相手に送り、確認応答が返ってくるのを待つ状態。
FIN-WAIT-2 : FINに対する確認応答を受け取り、相手からのFINを待つ状態。
CLOSE-WAIT : 相手から先にFINを受け取り、アプリケーションがクローズ可能となるのを待つ状態。クローズ可能になったら相手にFINに対する確認応答を送る。
LAST-ACK : FINセグメントを送って、その確認応答を待っている状態。
TIME-WAIT : 「FIN-WAIT2」でFINセグメントを受信し、確認応答を返した状態。相手が確認応答を受信完了することを保証するため、十分な時間待つ。RFC 793 では最大4分間この状態でコネクションを保つことができるとされており、これをMSL (maximum segment lifetime) と呼ぶ。
CLOSED : コネクションがクローズした状態。
プロトコル操作 > コネクション確立

詳細は「3ウェイ・ハンドシェイク」を参照
コネクションを確立する際、TCPでは3ウェイ・ハンドシェイクを行う。
クライアントがサーバと接続する前、サーバはコネクション可能なようにポートをバインドしておかなければならない。これをパッシブ・オープンと呼ぶ。サーバ側がパッシブ・オープンになっていれば、クライアントはアクティブ・オープンを開始できる。コネクションを確立するための3ウェイ・ハンドシェイクは次のようになる。
SYN: クライアントはサーバにSYNを送り、アクティブ・オープンを行う。クライアントはこの際に無作為な値Aを選び、SYNセグメントのシーケンス番号とする。
SYN-ACK: それに対してサーバはSYN+ACKを返す。確認応答番号は受信したSYNセグメントのシーケンス番号に1を加えたもの (A + 1) とし、SYN+ACK のシーケンス番号は別の無作為な値 B とする。
ACK: クライアントがサーバからの SYN+ACK に対して ACK を返す。その際のシーケンス番号は受信した SYN+ACK の確認応答番号 (A + 1) とし、確認応答番号は SYN+ACK のシーケンス番号に1を加えた値 (B + 1) とする。
この時点でクライアントとサーバ双方がコネクション確立の確認応答を受け取ったことになる。
プロトコル操作 > リソースの使い方

多くの実装では、テーブルの1エントリを動作中のOSプロセスとのセッションにマッピングする。TCPセグメントにはセッション識別子がないため、通信している双方でクライアントのアドレスとポートでセッションを識別する。パケットを受信すると、TCPソフトウェアはそのテーブルを参照して、対応するプロセスを見つける。
サーバ側でのセッション数はメモリ容量にのみ制限され、コネクション確立要求がくるたびに増えていく。しかし、クライアントはサーバに最初のSYNセグメントを送る前に無作為にポートを選んで確保しなければならない。このポートはコネクションをクローズするまで確保され続け、実質的にクライアントの持つIPアドレス毎の外に出て行くコネクション数を制限している。アプリケーションが不要になったコネクションをクローズしそこねると、空いているポートが足りなくなり、新たなTCPコネクションを確立できなくなる。
また、通信する双方で確認応答を受け取っていない送信済みデータとアプリケーションに渡す前の受信データを格納しておく領域を確保する必要がある。
プロトコル操作 > データ転送

TCPが提供する機能（#機能を参照）は以下の機構で提供される。
順序保証: 受信側でシーケンス番号を使って並べ替え
到達保証/再送: 確認応答のないセグメントは再送
誤りのないデータ転送: チェックサム
フロー制御: 受信側は常にどのくらいのデータを受け取れるかを知らせている（スライディングウィンドウで制御している）。受信側のバッファが一杯になると、次の確認応答ではウィンドウサイズを0とするので送信が停止し、バッファ内のデータを処理する余裕ができる。
プロトコル操作 > データ転送 > 高信頼転送

TCPは「シーケンス番号」を使ってデータの各バイトを識別する。シーケンス番号は双方のホストが送信するバイト列に先頭から振られる番号であり、それによってデータがどう分割されても、順番が入れ替わっても、転送中に失われても、元のデータを復元できる。ペイロードの各バイトを送るたびにシーケンス番号をインクリメントしなければならない。3ウェイ・ハンドシェイクの最初の2ステップで、双方のホストは初期シーケンス番号 (ISN) をやりとりする。この番号は任意であり、TCPシーケンス番号予測攻撃への防御のために予測不可能な値とすべきである。
TCPは「累積確認応答」方式を採用しており、受信側が確認応答を返すとき、そのセグメントで示されている確認応答番号は、対応するシーケンス番号未満のデータを全て受信済みであることを示している。送信側はペイロードの先頭バイトのシーケンス番号をそのセグメントのシーケンス番号として設定する。受信側は次に受信することを期待しているバイトのシーケンス番号を確認応答番号に設定して確認応答を返す。例えば、送信側が4バイトのペイロードをシーケンス番号 100 で送信する場合、そのペイロードの4バイトのシーケンス番号は順に 100、101、102、103 である。受信側がこのセグメントを受信すると、その確認応答での確認応答番号は 104 となり、次のパケットで送られてくるペイロードの先頭バイトのシーケンス番号となっている。
累積確認応答に加えて、受信側は選択確認応答でさらなる情報を送ることができる。
送信側がネットワーク内でデータが失われたと判断した場合、データの再送を行う。
プロトコル操作 > データ転送 > 誤り検出

後述の#チェックサムの計算も参照。
シーケンス番号と確認応答は、パケットの重複、喪失パケットの再送、データの順序通りの並べ替えなどを扱っている。受信したパケットの内容が正しいことを確認するため、TCPにはチェックサムフィールドがある。チェックサムフィールドは設定必須の項目であり省略できない。
TCPチェックサムは、現在の標準から見れば弱い。データリンク層のビット誤り率が高ければ、TCPチェックサムとは別の誤り検出訂正機能が必要である。TCP/IPの下層であるデータリンク層には一般にCRCなどのもっと強力な検査機構があり、TCPチェックサムの弱さを一部補っている（例えば、PPPやイーサネット）。しかし、だからといって16ビットのTCPチェックサムが無駄というわけではない。実際、CRCで保護された通信路でパケットに誤りが残ることはよくあるが、エンドツーエンドの16ビットTCPチェックサムがそういった単純な誤りを捉えている。これはエンドツーエンド原理が機能している例である。
プロトコル操作 > データ転送 > フロー制御

TCPはエンドツーエンドのフロー制御プロトコルを使い、送信ペースが受信側にとって速すぎる状態になるのを防いでいる。様々な性能の機器が接続されたネットワークでは、フロー制御は欠かせない機構である。例えば、PCから性能の劣るPDAにデータを送る場合、PDAの性能に合わせて送信ペースを調整する必要がある。
TCPはスライディングウィンドウによるフロー制御を採用している。各TCPセグメントについて、受信側は「ウィンドウサイズ」フィールドで、そのコネクション用のバッファの空き容量に相当する今後受信可能なデータの量（バイト単位）を示す。送信側は確認応答を待ち合わせるまでに、そのフィールドで指定された量までのデータを送り、新たな確認応答でウィンドウサイズ・フィールドを確認してさらに送信できるデータ量を更新する。
受信側がウィンドウサイズを0としたとき、送信側は送信を停止してタイマ (persist timer) を起動する。このタイマは受信側のウィンドウサイズの更新セグメントが喪失してデッドロック状態になるのを防ぐためのものである（受信側がウィンドウサイズを更新しないと送信を再開できないため）。タイマがタイムアウトすると、送信側は小さなパケットを送り、その確認応答で受信側のウィンドウサイズが回復したかを調べる。
受信側での受信データの処理が遅いと、ウィンドウサイズの指定は小さいままとなる。これをSilly Window Syndrome（英語版） (SWS)と呼び、送信側は1度に数バイトのデータしか送れなくなり、TCPヘッダの方が大きな割合を占めるため転送効率が極端に低下する。そのような状況に陥らないようにするためのウィンドウ・アルゴリズムが RFC 813 (Window and acknowledgement strategy in TCP) に記載されている。
プロトコル操作 > データ転送 > 輻輳制御

TCPは高性能を達成し輻輳崩壊（ネットワーク性能が数桁のオーダーで低下する現象）を防ぐため、輻輳制御機構をいくつか備えている。ネットワークに流入させるデータレートを制御し、崩壊のきっかけとなるようなレート未満でデータを送るよう保つ。また、おおまかに最大最小公平（英語版）なフロー割り当てを目指す。
送信データへの ACK (確認応答)の有無は、送信側でネットワークの状態を推測する材料となる。これをタイマと組み合わせ、データのフローの振る舞いを変化させることができる。これを一般に輻輳制御またはネットワーク輻輳回避などと呼ぶ。
最近のTCP実装では、スロースタート（英語版）、輻輳回避（英語版）、TCP高速再送アルゴリズム（英語版）、ファストリカバリ(en, RFC 5681) という4つの相互にからみあったアルゴリズムを使用している。
スループットをあげるため輻輳しない限界まで送信側はスライディングウィンドウを大きくする必要があるが、ウィンドウサイズを調整する輻輳回避アルゴリズムは長年研究されている。一覧は 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（英語版） が使われている。
さらに送信側には「再送タイムアウト (RTO)」があり、送信してから確認応答が戻るまでの時間であるラウンドトリップタイム (RTT) を推算し、ばらつきも考慮して設定する。このタイマの動作は RFC 2988 で規定されている。RTTの推算には微妙な点がある。例えば、再送パケットのRTTを計算する場合は注意しなければならず、一般にカーンのアルゴリズム（英語版）やTCPタイムスタンプ（RFC 1323 参照）を使う。個々のRTTの標本から時系列で平均をとり、ジェイコブソンのアルゴリズムを使って Smoothed Round Trip Time (SRTT) を生成する。最終的にSRTT値がRTTの推算に使われる。
TCPを拡張して、喪失を高信頼に扱ったり、誤りを最小化したり、輻輳を制御してより高速化しようという試みが今も行われている。
プロトコル操作 > データ転送 > 遅延送信

詳細は「Nagleアルゴリズム」を参照
詳細は「TCP遅延ACK」を参照
最大セグメントサイズ以下の小さなパケットをばらばらと送るのは非効率なので、送信を遅延し、それらを1つのTCPパケットにまとめるのが、Nagleアルゴリズムである。同様に、複数のACKを1つにまとめるのが、TCP遅延ACKである。どちらも、送信を遅延させるという点においては同じだが、相互に影響し合い、遅延が増大するという問題があり、詳細はNagleアルゴリズムを参照。
プロトコル操作 > 最大セグメントサイズ

詳細は「最大セグメントサイズ」を参照
最大セグメントサイズ (MSS) はバイト単位で指定され、単一のセグメントとして受信可能な最大データ量を示す。性能を最大限発揮するにはIPフラグメンテーションを十分防げる程度に小さくする必要がある。IPフラグメンテーションが行われると、パケット喪失時の再送に時間がかかることになる。一般にコネクション確立時にMSSオプションを使って双方のMSSを通知するので、適切なMSSを決めるにはデータリンク層の Maximum Transmission Unit (MTU) から導出したMSSを通知すればよい。さらに送信側は経路MTU探索を使うことができ、通信相手との間にある経路でMTUが最小の部分を推定し、それを使ってMSSを動的に調整しIPフラグメンテーションを防ぐことができる。
MSS通知は「MSSネゴシエーション」とも呼ばれる。ネゴシエーションというと送信側と受信側が交渉して合意に達するかのように思われるが、実際には異なり、送信する方向によってそれぞれ異なるMSSが設定可能である。これは例えば一方がメモリ容量が小さいため、バッファ領域を大きくとれない場合などに起きる（発見したパスMTUより小さいこともありうる）。
プロトコル操作 > 選択確認応答

もともとのTCPプロトコルで採用されている累積確認応答方式を使うと、パケットを喪失したときに非効率になる可能性がある。例えば、10,000バイトのデータを10個のTCPセグメントで送信し、その最初のパケットが喪失したとする。もともとの累積確認応答プロトコルでは、受信側は1,000から9,999までのバイトは受信成功、ただし0から999までのバイトを含む先頭パケットの受信に失敗したという風に伝えることができないので、送信側は10,000バイト全体を再送しなければならない。
このため RFC 2018 で「選択確認応答 (SACK)」オプションが追加された。これは、通常の累積確認応答とは別に、受信側が不連続なブロックを正しく受信したという確認応答を返せるようにしたものである。選択確認応答にはオプション部分にいくつかのSACKブロックを指定し、SACKブロックには正しく受信できた連続な範囲のシーケンス番号の開始点と終了点を指定する。例えば、先ほどの例では 1000 と 9999 のシーケンス番号をSACKオプションで示せばよい。すると送信側は 0 から 999 までのバイトを含む最初のパケットだけを再送する。
SACKオプションの拡張として RFC 2883 で定義されたデュプリケートSACK (D-SACK) オプションがある。パケットの順序がばらばらになると、送信側への確認応答も順序どおりにならないため送信側でパケット喪失と勘違いし、喪失したと思われるパケットを再送することがあり、同時にネットワーク輻輳を防ぐため送信ペースを落とす。このとき、受信側が D-SACK オプションで再送パケットが重複していることを通知すれば、遅くなっていた送信ペースを元に戻すことができる。
SACKオプションは必須ではなく、両者がサポートしている場合だけ使われる。これはコネクション確立時に調整される。SACKオプションは主なTCPスタックでサポートされており、広く使われている。選択確認応答は Stream Control Transmission Protocol (SCTP) でも使われている。
プロトコル操作 > ウィンドウスケーリング

広帯域ネットワークをより効率的に使うには、TCPウィンドウのサイズを大きくする必要がある。TCPヘッダのウィンドウサイズのフィールドは16ビットで、2バイトから65,535バイトまでしか設定できない。
ウィンドウサイズ・フィールドは拡張できないので、スケールファクタ（英語版）が導入されている。RFC 7323 で定義されているウィンドウスケール・オプションを使えば、最大ウィンドウサイズを 65,535 バイトから 1 ギガバイトに拡張できる。ウィンドウサイズのスケールアップはTCPのチューニング (en) に必須の要素である。
ウィンドウスケール・オプションは3ウェイ・ハンドシェイクの際にしか使われない。ウィンドウスケール・オプションのオプション値は、16ビットのウィンドウサイズ・フィールドの値を左にシフトするビット数を表している。ウィンドウスケールの値は0（シフトしない）から14まで指定でき、通信の双方向で別々に設定できる。どちらの方向もSYNセグメントのオプションとして通知する。
一部のルーターやファイアウォールは、このスケールファクタを転送時に書き換えることがある。すると送信側と受信側でウィンドウサイズの認識が異なることになり、トラフィックが不安定になって、非常に低速になることがある。
プロトコル操作 > TCPタイムスタンプ

TCPタイムスタンプは RFC 1323 で定義されており、パケット送出の順序をTCPレベルで知ることが出来る。TCPタイムスタンプはシステムクロックに合わせているわけではなく、無作為な値から開始する。多くのOSはこのタイムスタンプ値をミリ秒単位でインクリメントする。ただし、RFCは単に時間経過に比例して増加すべきだとしているだけである。
タイムスタンプのフィールドは2つある。
4バイトの送信側タイムスタンプ値（自分のタイムスタンプ）
4バイトの応答タイムスタンプ値（相手から直近に受け取ったタイムスタンプ値）
TCPタイムスタンプは PAWS (Protection Against Wrapped Sequences) と呼ばれるアルゴリズム（RFC 1323 参照）で利用する。PAWSは、2の32乗まであるシーケンス番号が一周してしまう場合に使われる。シーケンス番号はデータバイト毎に振られるので、最大4ギガバイトしか表せないが、最近の高速ネットワークでは1分以内に一周する可能性があり、再送が必要になったとき、現在の周回なのか前の周回なのかを識別するのにタイムスタンプを使う。
RFC 1323 の2.2節では、ウィンドウサイズは1ギガバイトまでとされているため、多くの実装でスケールオプションの最大値を14までとしている。
また、Eifel detection アルゴリズム (RFC 3522) でもTCPタイムスタンプを使っており、再送の原因がパケット喪失なのか順序がばらばらになったせいなのかを判断する。
プロトコル操作 > 帯域外データ

ストリームが完了するのを待たずに、キューイングされたストリームに割り込むことができる。この場合、緊急 (urgent) と指定したデータを使う。それによって受信側プログラムが緊急データをすぐさま処理すべきであることを知らせる。その処理が終了すると、もとのストリーム・キューの処理を再開する。例えば、リモートログインのセッションにTCPを使っているとき、ユーザーが実行中のプログラムをアボートさせるキーシーケンスを送るときなどに使われる。プログラムが暴走したときなど、そのプログラムの出力を待っているのではなく、強引にアボートさせたいときに必須となる。
帯域外データの概念は現在のインターネット向けの設計ではない。緊急ポインタは相手ホストでの処理を変えるものであって、ネットワーク上の処理は何も変わらない。緊急ポインタのあるセグメントがリモートホストに到着したとき、若干異なる2つのプロトコルの解釈があり、単一バイトの帯域外データしか信頼できないという状況になっている。そのため滅多に使われず、実装も貧弱になる傾向がある
。
プロトコル操作 > 強制的データ送出

通常、TCPは送信すべきデータが最大セグメントサイズ (MSS) まで溜まるか、200ミリ秒経過するまで待つ（Nagleアルゴリズムで小さいメッセージを単一パケットにまとめようとするため）。これは例えばファイル転送のような一定の送信が要求される場合に問題となることがある。例えば、送信ブロックが一般的な4KBで、MSSも一般的な1460バイトだとする。すると1ブロックが3セグメントで送信され、最後の1セグメントはMSSに満たないことになる。すると、2パケットまでは約1.2ミリ秒で送信され、1176バイトの3パケット目は197ミリ秒待ってから送信ということになる。
Telnetの場合、ユーザーがキーを押下するたびに通信先からエコーバックされて画面に文字が表示される。すると、1文字押下するたびに200ミリ秒待たされることになり、非常にストレスになる。
この場合、ソケットのオプション TCP_NODELAY を使ってデフォルトの200ミリ秒の送信遅延を変更することができる。
RFCには PSH フラグを使って「受信側TCPスタックでそのデータを即座にアプリケーションに送る」という機能が定義されている。しかしソケットにはこれを制御するインタフェースがなく、プロトコルスタックの実装に任されている。
プロトコル操作 > コネクション終了

コネクション終了フェーズは多くの場合「4ウェイ・ハンドシェイク」を使い、コネクションの双方がそれぞれ独立に終了できる。一方がコネクションを終了したい場合、FINセグメントを送信し、相手がそのACKを返す。相手も同様にFINを送ってACKを受信することでコネクションを終了する。両方のFIN/ACK交換が済むと、最後にACKを送った側（先にFINを送った側）がタイマを設定してタイムアウトするまで当該ポートを別のコネクションに再利用できないようにする。これによって配送が遅れていたパケットが新たなコネクションで受信されて混乱するのを防ぐ。
コネクションは「ハーフオープン」という状態にもでき、一方だけ終了していても、もう一方はデータを送り続けることができる。終了した側はもう一方が終了するまで受信可能の状態を継続する。
コネクション終了を3ウェイ・ハンドシェイクで行うこともでき、ホストAのFIN送信に対してホストBが FIN+ACK で応答し、ホストAがACK応答する。実際にはこれが最も一般的である。
両方から同時にFINセグメントを送りあい、双方がACKを返すということもありうる。FIN/ACKシーケンスが並行して行われるため、2ウェイ・ハンドシェイクと呼ぶこともできる。
脆弱性

TCPは様々な方法で攻撃される可能性がある。TCPの完全なセキュリティアセスメントの結果は、認識されていた問題の考えうる対策と共に2009年に公表され、その後もIETF内で進められている。
脆弱性 > DoS攻撃

IPスプーフィングを使い、悪意を持って作ったSYNパケットを繰り返し送信することで、偽の接続に対処するために対象サーバの多大な量のリソースを消費させることができる。これを SYN flood 攻撃と呼ぶ。この問題への対策として提案された方法として、SYN cookies や暗号的パズルがある。Sockstress も類似の攻撃法だが、システムのリソース管理によって効果を和らげることができる。オンラインマガジン Phrack 66号では、TCPの Persist Timer に存在する脆弱性を利用した改良型DoS攻撃の分析を行っている。
脆弱性 > コネクション乗っ取り

詳細は「TCPシーケンス番号予測攻撃」を参照
TCPセッションを盗聴できパケットをリダイレクトできる攻撃者は、TCPコネクションを乗っ取ることができる。その場合、攻撃者は進行中の通信からシーケンス番号を読み取り、ストリームにおける次のセグメントを装った偽のセグメントを作る。そのような簡単な乗っ取りで、通信中の一方に1つのパケットを誤って受け取らせることができる。受け取ったホストが余分なセグメントへの確認応答をコネクションのもう一方に返すと、同期が失われる。ARPまたはルーティング攻撃を組合わせることで、乗っ取ったTCPコネクションの制御を完全に奪うことができる。
RFC 1948 が登場する以前は異なるIPアドレスを真似ることは難しくなく、初期シーケンス番号は容易に推測可能だった。そのため攻撃者はARP/ルーティング攻撃を併用することなく、適当な一連のパケットを受信者に送信し、異なるIPアドレスからのものだと信じさせることができた。その際、偽装したIPアドレスの本来のホストがダウンしていれば十分であり、Dos攻撃でそのホストをダウンさせればよかった。以上のような理由から、初期シーケンス番号のランダムな選択が行われるようになった。
TCPポート

詳細は「ポート (コンピュータネットワーク)」を参照
TCPにおけるポートは「ホスト内アドレス」である。
単一のホストでは複数のプロセス（≒ アプリケーション）が動作している。TCPはホスト内の"部屋番号"に相当するポート、ポートとインターネットアドレスの組み合わせであるソケット（英: socket）を定義し、このソケット-ソケット間で通信を行う。単一ホスト内に複数ポートが存在することで、単一のホスト上で複数のプロセスが同時にTCP通信できる（多重化）。各ポートはポート番号として知られるポート識別子が設定されており、プロセスとポートを結びつけることでそのプロセスへの通信を可能にする。ポート番号は16ビット符号なし整数 (0-65535) の範囲をもつ。
コネクション（英: connection）は一組のソケットで識別される論理的通信路である。すなわち「ソケット 172.16.0.0:1024 とソケット 192.168.0.0:80 を繋ぐ論理的通信路」といった形で識別されるものがコネクションである。受信したTCPセグメントは特定のコネクションに属すると識別される。
ポート番号は大きく3つに分類されており、ウェルノウン (well-known)、レジスタード (registered)、ダイナミック/プライベート (dynamic/private) がある。ウェルノウンポート番号は Internet Assigned Numbers Authority (IANA) が割り当てを行っており、主にシステムレベルや重要なプロセスで使われている。サーバとして動作する有名なアプリケーションは、それらのポートを使いコネクション確立要求を待ち受けているのが一般的である。例えば、FTP (20, 21)、SSH (22)、TELNET (23)、SMTP (25)、HTTP (80) などがある。レジスタードポート番号は一般にエンドユーザー用アプリケーションが送信元のエフェメラルポートとしてサーバに接続するのに使うが、サードパーティが登録した名前を持ったサービスの識別にも使われている。ダイナミック/プライベートポート番号もエンドユーザーのアプリケーションで使えるが、一般にそのような使い方は少ない。ダイナミック/プライベートポート番号は、それを使っている特定のTCPコネクションでしか意味を持たない。