HTTPS по сравнению со сравнением скорости HTTP
Я не понимаю, чего вы здесь добиваетесь: но в отношении массивов и того, как вы добавляете элементы и печатаете их значения, вот один из способов достижения этого:
var sentence = []
var words = ['this', 'is', 'one', 'way', 'of', 'push', 'to', 'an', 'array','and','print', 'the', 'values']
for(var i = 0; i < words.length; i++){
sentence.push(words[i]);
}
console.log("Here's my sentence: " + sentence.join()) // => Here's my sentence: this is one way of pushing to an array and print the values
или если вы просто хотите распечатать каждый элемент в массиве:
for(var i = 0; i < sentence.length; i++){
console.log(sentence[i]);
}
5 ответов
Если вы посмотрите на ваше время, у http больше время ожидания и меньше время получения. https, с другой стороны, имеет меньшее время ожидания и большее время получения. Я бы интерпретировал это как http-порт на сервере общего хостинга более загружен, поэтому запрос остается в очереди дольше, пока не будет принят сервером. После принятия запросы передаются быстрее, чем https. На порту https на сервере меньше трафика, поэтому запрос обрабатывается быстрее, но требует больше времени для передачи.
При любом сравнении https и http вам необходимо учитывать большее время для подтверждения каждого запроса для https по сравнению с http. Вы должны увидеть ухудшение при выполнении большого количества мелких запросов.
Я думаю, что более быстрая производительность по HTTPS не случайна.
Обратите внимание на две вещи о ваших результатах:
- HTTP всегда быстрее для первого «итогового» результата, но медленнее для последующих итогов.
- Результаты HTTPS более последовательны.
Современные балансировщики нагрузки обычно включают сжатие во время использования SSL для повышения производительности. Хотя первоначальное SSL-квитирование действительно имеет существенную задержку, механизмы, используемые для поддержки сеанса («возобновленное квитирование» и симметричное шифрование вместо асимметричного шифрования), добавляют лишь незначительную задержку. В результате, если ваши сеансы не будут короткими, вы получите от производительности больше выигрыша от сжатия, чем от обслуживания сеансов.
Общепринятое мнение, что SSL требует значительных задержек, устарело (если ваши сеансы не очень короткие). Некоторые инженеры Google написали статью , объясняющую, как некоторые предыдущие предположения о SSL больше не верны.
https работает следующим образом: Сначала выполняется четырехстороннее рукопожатие (по крайней мере, если я правильно помню, это было четырехстороннее), здесь клиент и сервер согласовывают алгоритм симметричного шифрования, используемый позже, и обмениваются сертификатами (содержащими открытые ключи).
Они обмениваются сеансом (ключом для симметричного шифрования позже) с использованием криптографии с открытым ключом.
Теперь они отправляют сообщения, зашифрованные с помощью сеансового ключа и некоторого алгоритма шифрования (3des, aes, rc4, rc5 и т. Д.). Поскольку симметричное шифрование - не такая дорогостоящая операция, разница во времени загрузки не так велика.
Тот факт, что у вас на меньше времени ожидания, объясняется тем, что у вас, вероятно, меньше трафика на http-порте или меньше трафика на время, когда вы выполняли запрос https, по сравнению с запросами http.
Таким образом, для оптимизации производительности вы должны использовать как можно меньше подключений https, поскольку рукопожатие является относительно дорогостоящей процедурой.
Вы заходите на свой сайт через прокси-сервер? Если это так, возможно, вы увидите лучшую производительность, потому что прокси-сервер обходится или сокращается до использования только обработки начальных запросов CONNECT.
Прокси-сервер может проверять и кэшировать контент при использовании HTTP, что приводит к снижению производительности.
Вы также можете принять во внимание, что документы HTTPS будут почти никогда не кэшироваться нигде, кроме браузера пользователя, поэтому вы можете обнаружить, что хотя для отдельного пользователя нет большой разницы, документ HTTP может быть значительно быстрее для большого количества людей, использующих кеш. (В некоторых местах интернет-провайдеры все еще часто ставят своих клиентов через общий прокси-кеш)
Если вы не возражаете против того, чтобы пользователи делили это, конечно.