Pascal Hambourg: > Le 16/06/2016 22:13, Dan Purgert a écrit : > >> as well as making the overall amount of data >> transmitted somewhat larger. This is because encrypted blocks have >> specific size requirements (...) >> >> Remeber that a single packet can only carry 1460 bytes, before >> accounting for services that specify MTUs <1500 . If you're using >> something like 64-byte blocks for the encryption scheme (which is fairly >> common, so I'm going with that from here on out), you're limited to only >> sending 1408 bytes / packet of actual data, assuming zero overhead. For >> the 660 602 880 bytes of "cd1" from the debian installer suite, this >> means you're transmitting 469,178 fully loaded packets, plus 1 partial >> (approx 315 bytes) ... or a total transmission of 689 691 975 bytes. > > Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt > that it cares about IP packet size. The task of splitting the TCP payload > stream into IP packets is done by the TCP layer.
Sure, but if your encryption scheme wastes payload in yout packets you
have more overhead for TCP/IP headers in each packet. I have yet to
actually meet someone who optimizes on that level but at Google scale
these things obviously matter.
J.
--
Whenever I hear the word 'art' I reach for my visa card.
[Agree] [Disagree]
<http://archive.slowlydownward.com/NODATA/data_enter2.html>
signature.asc
Description: Digital signature
