59

どれが効率的ですか？SSH:// または Git:// (ファイル圧縮)

Git では、git プロトコルがスマートであることを理解しています。これは、通信の両端にファイル転送を圧縮するプロトコル エージェントがあり、ネットワーク帯域幅を効率的に使用してクローンを高速化するためです。

O'Reilly の本から、次のステートメントを見つけました。

For secure, authenticated connections, the Git native 
protocol can be tunneled over an SSH connection using
the following URL templates:

ssh: //[user@]example.com[:port]/path/to/repo.git
ssh: //[user@]example.com/path/to/repo.git
ssh: //[user@]example.com/~user2/path/to/repo.git
ssh: //[user@]example.com/~/path/to/repo.git*

著者が言っていることが本意かどうかはわかりません。彼は、Git プロトコルが SSH 経由でトンネリングされることについて話しています。

私の見解では、git ポート (エージェント ポート) に接続しない限り、プロトコルは有効ではありません。また、SSH は単なる非圧縮ファイル転送です。しかし、著者によると、SSH を使用する場合、Git プロトコルはその上でトンネリングされると彼は言います。では、SSH は GIT でよりスマートですか?

Von Cさん、ご回答ありがとうございます。「ネットワーク プロトコル (HTTP と Git) は一般的に読み取り専用です」rwでデーモンを実行すると、 Git を作成できます--enable=receive-pack。

以下は私の懸念事項です。
git プロトコルがスマートであると言う場合、実行するgit cloneと、Git サーバー エージェントはクライアントに送り返されるデータを圧縮するため、クローンはより高速になるはずです。私のユースケースでは、香港に Git サーバーを設定し、サンノゼやその他の国でも使用する予定です。そのため、遅延の問題のためにネットワーク上で効率的になりたいと考えています。

だから私の質問は、いつ私git clone ssh://user@server/reposlocがgitプロトコルの利点を得られるのかということです? O'Reilly の著者の本によると、彼は git が ssh 経由でトンネリングされていることを意味し、サーバーで git デーモンが実行されていない場合、git プロトコルはどのように機能するのでしょうか。

SSh://xyz... を使用すると、ssh プロトコルと git プロトコルの両方の利点が得られますか?

事前に回答をお待ちしております。

4

7 に答える 7

55

更新 2010-2014:

Git 1.6.6+ (2010) およびスマート http プロトコルの実装以降、ssh と https はどちらも同等です。

スマートhttp

リポジトリへの読み取り/書き込みアクセスに ssh または https を使用できるようになりました。リモート サーバーがスマート http をサポートしているかどうかを検出する
こともできます。 プロキシを使用する必要がある場合は、適切な環境変数を追加してください。

Yousha Aleayoubがコメントで言及しているように、2015 年第 3 四半期:

GitHub 「どのリモート URL を使用すればよいですか?」

クローン URL は、パブリックおよびプライベートのhttps://すべてのリポジトリで利用できます。
それらはスマートであるため、リポジトリへのアクセス許可に応じて、読み取り専用または読み取り/書き込みアクセスのいずれかを提供します。

git-http-backendは次のとおりです。

http://およびhttps://プロトコルを介してリポジトリにアクセスする Git クライアントに Git リポジトリのコンテンツを提供する単純な CGI プログラム。
このプログラムは、スマート HTTP プロトコルと下位互換性のあるダム HTTP プロトコルの両方を使用してフェッチするクライアントと、スマート HTTP プロトコルを使用してプッシュするクライアントをサポートします。

元の回答 (2010 年 7 月):

Pro Git Bookから:

おそらく、Git の最も一般的なトランスポート プロトコルは SSH です。
これは、サーバーへの SSH アクセスがほとんどの場所で既に設定されているためです。設定されていない場合でも、簡単に設定できます。

また、SSH は、簡単に読み書きできる唯一のネットワーク ベースのプロトコルでもあります。他の 2 つのネットワーク プロトコル (HTTP と Git) は一般的に読み取り専用であるため、それらを未処理の大衆に利用できるようにしたとしても、独自の書き込みコマンドには SSH が必要です。

SSH は認証済みネットワーク プロトコルでもあります。また、ユビキタスであるため、一般的にセットアップと使用が簡単です。

したがって、Git プロトコルよりも「スマート」というわけではなく、Git プロトコルでは対処されない特定の機能を補完するプロトコルにすぎません。

Git プロトコルの欠点は、認証がないことです。一般に、Git プロトコルがプロジェクトへの唯一のアクセスになることは望ましくありません。
通常、プッシュ (書き込み) アクセス権を持つ少数の開発者には SSH アクセスと組み合わせて使用​​し、それ以外の開発者にはgit://読み取り専用アクセスを使用させます。

また、ポート 9418 へのファイアウォール アクセスも必要です。これは、企業のファイアウォールが常に許可する標準ポートではありません。大企業のファイアウォールの背後では、この目立たないポートがブロックされることがよくあります。

(そのため、私のショップでは、読み取りアクセスであっても、git だけでなく ssh+git を使用する必要があります: 9418はブロックされています...)

于 2010-07-14T17:35:33.273 に答える
41

このページの2番目の部分を見てください

唯一の「ダム」プロトコルはストレートHTTPであり、サーバー上で特別な作業を必要としません。git：//プロトコルとssh：//プロトコルの両方で、git upload-packプロセス（デーモンではない）は、を実行しているクライアントと通信するサーバー上でフォークされますgit fetch-pack。ssh：//とgit：//の両方で、「スマート」な通信が得られます。

于 2010-07-14T20:20:31.787 に答える
6

(@erjiang の回答にコメントを追加したかったのですが、StackOverflow の評判が十分でないため、許可されていません。)

Git 1.6.6 以降、HTTP はもはや「ばか」ではなくなったようです。Git Web サイトのブログから:

しかし、昨年末 (2009 年) にバージョン 1.6.6 がリリースされた時点で、Git は HTTP プロトコルを git または ssh バージョンとほぼ同じくらい効率的に使用できるようになりました。

于 2014-01-13T11:42:00.930 に答える
4

ssh 経由で git にアクセスすると、ssh 経由で git プロトコルがトンネリングされるだけで、セットアップがより簡単になり、より安全になります。これは、リモート リポジトリにアクセスするための推奨される方法です。

これは、ssh メカニズムを介してユーザー認証を強制できるため、実際には裸の git プロトコルよりも「スマート」です。git は、トランスポート層に関係なく、クライアント上ですべての圧縮と非圧縮を行い、サーバー上で解凍します。

「git」サーバーはこれを行いません。これはすべて、ssh を使用している場合にも発生します。リモート リポジトリに書き込みできるようにする場合は、git サーバーを使用しないでください。読み取り専用アクセスが必要な場合は、git または HTTP トランスポートは「OK」ですが、リポジトリに書き込む必要がある開発者がいる場合は、ssh を使用する必要があります。git サーバーのトンネルを設定すると、複雑さと構成が増えるだけで、脆弱で何も得られません。

于 2010-07-14T17:34:12.840 に答える
1

ウィキペディアから：

SSH トンネルをセットアップするには、指定したローカル ポートをリモート マシンのポートに転送するように SSH クライアントを構成します。SSH トンネルが確立されると、ユーザーは指定されたローカル ポートに接続して、ネットワーク サービスにアクセスできます。ローカル ポートは、リモート ポートと同じポート番号である必要はありません。

ある種の ASCII アート表現が必要な場合:

Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data
于 2010-07-14T17:33:26.133 に答える
0

git clone 中にパック ファイルをすばやく検索すると、サーバーからクライアントに送信される単一のパック ファイルが一覧表示されます。パック ファイルは .git/objects/pack/pack-XXXX.pack の下に一覧表示されます。サーバーからクライアントに送信されるファイルは、最初にパックされ、圧縮されます。次に、パックされたコンテンツの単一のコピーがあります。これは、サーバー側で lsof -p を使用し、クライアント側で lsof -p を使用してパックされたファイルを比較すると確認できます。サンプルケースでは、200MB のファイルがサーバーからクライアントにアップロードされます....

1) Server side 
   lsof -p 8079 | grep pack
   git-uploa 8079  REG  253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack
   git-uploa 8079  REG  253,2   1703472 5140076 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.idx
   git-uploa 8079  REG  253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack

2) Client side
   lsof -p 3140 | grep pack
   git     3140  3u   REG    8,1 101031935 3681610 /home/client/work/work0617/work0617/.git/objects/pack/tmp_pack_pRfYPa

 3) The server side pack file 277MB. The file on the client side is 101MB and growing. So a single compressed file is copied over.
于 2014-06-17T17:04:11.307 に答える