Совершенно необязательно именно гарнитуру — просто используется разъем TRRS вместо двух обычных TRS. В этот TRRS можно впихнуть, что угодно — например, разветвитель.
<sarcasm>Отлично! Значит, вместо распылителей воды сверху размещаем еще один огромный вентилятор, а нижние будут просто крутиться в обратную сторону. У вас не найдется $1.5 млн?</sarcasm>
Если вне контекста децентрализации, то, например, возможна балансировка нагрузки для отдачи большого содержимого. Например, стриминг видео можно было бы делать одновременно с нескольких серверов — несколько серверов-хранилищ медленно извлекают нужные данные и передают их «фронтэнду», который пересылает данные клиенту по мере доступности.
Тут, скорее, не на сервер пересылать фрагменты, а от сервера. Допустим, у нас есть удаленный сервер, являющийся шлюзом в любую децентрализованную сеть, в которой содержимое хранится в виде фрагментов. Один документ может быть разбит на несколько фрагментов, и каждый из фрагментов нужно запрашивать отдельно, у тех пиров, у которых этот фрагмент есть — как в BitTorrent, или в DirectConnect, или в Kad, или где угодно, где используется эта простая и эффективная схема расшаривания.
Так как сервер запрашивает фрагменты параллельно, доступны они становятся не в порядке следования в результирующем файле. Например, сначала может быть получен фрагмент 5, затем 3, затем 1, затем 2, и только после этого 4. В нынешнем HTTP/1.1, чтобы отдать такой ресурс клиенту, серверу приходится аккумулировать у себя эти фрагменты — №5 и №3 сохранить, пока они не будут получены, когда будет получен №1, отдать его клиенту, и опять ждать, пока появится фрагмент №2, после чего отправить и его тоже. Так как третий фрагмент уже был на момент получения второго, их можно отправить вместе, после чего ждать четвертый. После получения четвертого отдать вместе с пятым и закрыть передачу.
Если использовать unordered chunks, то можно передавать фрагменты именно тогда, когда они доступны, и дать возможность клиенту уже частично извлечь какую-то информацию из того, что было отдано — например, передать фрагменты дальше, или, если это какой-нибудь архив, дать возможность извлечь полностью доступные файлы, или проиграть фрагмент видео, или связаться с другим сервером, у которого может быть этот ресурс, и запросить недостающие фрагменты в явном виде.
Теперь нужно популяризовать SCTP, как отличный протокол, поверх которого может работать http2.
По поводу того, чего не хватает — в HTTP/1.1 сильно не хватает возможности пересылать ответ по кускам, но не так, как это делает Transfer-Encoding: chunked, а без сохранения порядка, сродни тому, как скачиваются ресурсы в децентрализованных сетях. Чтобы сервер мог отправлять клиенту фрагменты запрошенных данных тогда, когда они станут доступны самому серверу. Кто-нибудь в курсе, в http2 есть возможность добиться этого?
Хабр не использует динамическую предзагрузку контента, поэтому на момент загрузки комментария со спойлером содержимое уже есть в DOM, и обладатели узеньких каналов или помегабайтной тарификации уже получили эту картинку, даже если спойлер не откроют. Таки дела.
Почему хорошим людям просто не собраться и не запретить незащищенные соединения? Вычислительная сторона SSL давно перестала быть проблемой для современного железа, разве нет?
А силы поверхностного натяжения не удержат «блямбу» в целости, лишь вытянув её в еще более аэродинамичную форму, некое подобие «копья»? Хотя, возможно, я переоцениваю эти силы, и вы правы.
<sarcasm>Отлично! Значит, вместо распылителей воды сверху размещаем еще один огромный вентилятор, а нижние будут просто крутиться в обратную сторону. У вас не найдется $1.5 млн?</sarcasm>Так как сервер запрашивает фрагменты параллельно, доступны они становятся не в порядке следования в результирующем файле. Например, сначала может быть получен фрагмент 5, затем 3, затем 1, затем 2, и только после этого 4. В нынешнем HTTP/1.1, чтобы отдать такой ресурс клиенту, серверу приходится аккумулировать у себя эти фрагменты — №5 и №3 сохранить, пока они не будут получены, когда будет получен №1, отдать его клиенту, и опять ждать, пока появится фрагмент №2, после чего отправить и его тоже. Так как третий фрагмент уже был на момент получения второго, их можно отправить вместе, после чего ждать четвертый. После получения четвертого отдать вместе с пятым и закрыть передачу.
Если использовать unordered chunks, то можно передавать фрагменты именно тогда, когда они доступны, и дать возможность клиенту уже частично извлечь какую-то информацию из того, что было отдано — например, передать фрагменты дальше, или, если это какой-нибудь архив, дать возможность извлечь полностью доступные файлы, или проиграть фрагмент видео, или связаться с другим сервером, у которого может быть этот ресурс, и запросить недостающие фрагменты в явном виде.
По поводу того, чего не хватает — в HTTP/1.1 сильно не хватает возможности пересылать ответ по кускам, но не так, как это делает
Transfer-Encoding: chunked, а без сохранения порядка, сродни тому, как скачиваются ресурсы в децентрализованных сетях. Чтобы сервер мог отправлять клиенту фрагменты запрошенных данных тогда, когда они станут доступны самому серверу. Кто-нибудь в курсе, в http2 есть возможность добиться этого?