On Thu, May 24, 2012 at 11:17 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Colby Ranger <cranger@xxxxxxxxxx> writes:
>
>> Git over HTTPS has a high request startup latency, since the SSL
>> negotiation can take up to a second. In order to reduce this latency,
>> connections should be left open to the Git server across requests
>> (or invocations of the git commandline).
>>
>> Reduce SSL startup latency by running a daemon job that keeps
>> connections open to a Git server. The daemon job
>> (git-remote-persistent-https--proxy) is started on the first request
>> through the client binary (git-remote-persistent-https) and remains
>> running for 24 hours after the last request, or until a new daemon
>> binary is placed in the PATH. The client determines the daemon's
>> HTTP address by communicating over a UNIX socket with the daemon.
>>>From there, the rest of the Git protocol work is delegated to the
>> "git-remote-http" binary, with the environment's http_proxy set to
>> the daemon.
>>
>> Signed-off-by: Colby Ranger <cranger@xxxxxxxxxx>
>
> Clever. Do you have some numbers?
$ (for i in {1..5}; do time git ls-remote
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
>/dev/null;done) 2>&1 | grep real
real 0m0.193s
real 0m0.175s
real 0m0.191s
real 0m0.173s
real 0m0.194s
$ (for i in {1..5}; do time git ls-remote
persistent-https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
>/dev/null;done) 2>&1 | grep real
real 0m0.208s
real 0m0.085s
real 0m0.079s
real 0m0.067s
real 0m0.059s
That initial 208ms run was the local proxy starting, and the
connection being established. Its similar to the normal case.
Subsequent executions have lower latency.
> If this persistent proxy weren't in the picture, the git client would
> directly delegate its communication with the origin server to
> git-remote-https, and git-remote-https would interact with the credential
> API to handle authentication for "https://origin.server.xz/repo";.
Yes.
> How does the persistent proxy sitting in between your git client and the
> origin server and/or the real proxy you have at the perimeter of your
> network interact with respect to authentication/authorization to access
> the repository or the real proxy? They will talk with the persistent
> proxy, and the persistent proxy will talk with the git client via
> git-remote-http, and I am assuming that this last git-remote-http will be
> the one that uses the credential API.
Yes.
> Would it ask credential for
> "https://origin.server.xz/repo";? "http://origin.server.xz/repo";? Or
> would it be "persistent-https://origin.server.xz.repo";?
IIRC it asks for "http://origin.server.xz/repo";.
The persistent-https code tells the git credential helper the
connection is "secure" (that is the proxy will use SSL as it exits the
local machine) by setting GIT_GOOGLE_CREDENTIAL_CORPSSO_ENABLE=1 in
the environment. This leaked from our internal version of the proxy,
Colby was supposed to scrub this string before open sourcing. :-)
So now everyone knows $DAYJOB = Google, we have a credential helper,
and it supports some sort of corporate single sign on. Whee.
>> contrib/persistent-https/COPYING | 202 +++++++++++++++++++++++++++++++++++
>
> I do not mind carrying this in the contrib/ area (I am assuming that
> distributing Apache licensed software that does not link with GPLv2 core
> is OK). It may be just me, but a file called COPYING that does not have
> GPL text in it was a bit surprising. I wonder if it is more customary to
> call it either LICENSE (or perhaps LICENSE-2.0)?
Agreed, LICENSE or LICENSE-2.0 is the right name for this file, not COPYING.
>> contrib/persistent-https/README | 62 +++++++++++
>> contrib/persistent-https/client.go | 178 ++++++++++++++++++++++++++++++
>> contrib/persistent-https/main.go | 82 ++++++++++++++
>> contrib/persistent-https/proxy.go | 190 ++++++++++++++++++++++++++++++++
>> contrib/persistent-https/release.sh | 45 ++++++++
>> contrib/persistent-https/socket.go | 97 +++++++++++++++++
>> contrib/persistent-https/tar.sh | 40 +++++++
>> 8 files changed, 896 insertions(+)
>
> It might deserve its own contrib/persistent-https/Makefile in addition to
> your internal "release" scripts, though.
Fair point.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html