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>
Attachment:
signature.asc
Description: Digital signature