GNU bug report logs - #22966
HTTPS with GnuTLS's 'session-record-port' is inefficient

Previous Next

Package: guix;

Reported by: ludo <at> gnu.org (Ludovic Courtès)

Date: Wed, 9 Mar 2016 22:03:02 UTC

Severity: normal

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22966 in the body.
You can then email your comments to 22966 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#22966; Package guix. (Wed, 09 Mar 2016 22:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to ludo <at> gnu.org (Ludovic Courtès):
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 09 Mar 2016 22:03:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guix <at> gnu.org
Subject: HTTPS with GnuTLS's 'session-record-port' is inefficient
Date: Wed, 09 Mar 2016 23:02:24 +0100
(guix build download) uses ‘session-record-port’ from (gnutls), which
returns a port to conveniently write to/read from the TLS session’s
“record” layer.

The problem is that every write to the port, that is, every call to
‘write_to_session_record_port’ in the GnuTLS bindings, leads to the
creation of one “Application Data” packet.

For instance, when (web requests) writes an HTTP GET request, it roughly
does:

  (display "GET" port)
  (display " " port)
  (display uri port)
  (display "\n\r" port)
  …

it ends up creating a lot of small Application Data packets.  When
debugging is enabled in (guix build download), that translates to things
like:

  gnutls: [14594|5] REC[0x152c9c0]: Preparing Packet Application Data(23) with length: 1 and min pad: 0
  gnutls: [14594|9] ENC[0x152c9c0]: cipher: AES-128-GCM, MAC: AEAD, Epoch: 1
  gnutls: [14594|5] REC[0x152c9c0]: Sent Packet[4] Application Data(23) in epoch 1 and length: 30

Terribly suboptimal.

The difficulty is that the session record port doesn’t do any caching by
itself, and it shouldn’t, because it’s the application’s responsibility.
So we might have to do our own caching and/or use ‘record-send’ and
‘record-receive!’ instead of ‘session-record-port’.

Ludo’.




Reply sent to ludo <at> gnu.org (Ludovic Courtès):
You have taken responsibility. (Tue, 15 Mar 2016 17:56:01 GMT) Full text and rfc822 format available.

Notification sent to ludo <at> gnu.org (Ludovic Courtès):
bug acknowledged by developer. (Tue, 15 Mar 2016 17:56:01 GMT) Full text and rfc822 format available.

Message #10 received at 22966-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: 22966-done <at> debbugs.gnu.org
Subject: Re: bug#22966: HTTPS with GnuTLS's 'session-record-port' is
 inefficient
Date: Tue, 15 Mar 2016 18:55:44 +0100
ludo <at> gnu.org (Ludovic Courtès) skribis:

> The problem is that every write to the port, that is, every call to
> ‘write_to_session_record_port’ in the GnuTLS bindings, leads to the
> creation of one “Application Data” packet.

Guix commit ec278439f3ff5dcd3d02c05099ba1724cc2459f1 works around it in
‘guix substitute’.

GnuTLS commit 0b1c136947878ccb600b4fa785ef257909104144 explains this in
the guile-gnutls manual.

I consider this bug closed.

Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 13 Apr 2016 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 14 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.