Mercury13

Хранение лучше в БД. Любой, хоть SqLite, хоть MyISAM, нет у вас каких-то причин искать СамуюМоднуюСУБД®.

Как промежуточный механизм передачи данных можно и JSON, если так хотите. Всё зависит от ваших навыков веб-разработчика. Поскольку мои веб-знания устарели лет этак на пятнадцать, я бы сначала сделал чистый PHP + не-AJAX, а потом думал бы.

Если хотите рендеринг шрифтов 1:1 — конвертируйте их в кривые!
Сколько раз твердили миру…

Помогает против пользователей. Не помогает против ботов. Зачем вообще такой сайт?

На самого себя.

Если, например, страница example.com/test.php, то эта страница и будет action.

Это две совершенно разные технологии. Они идут рука об руку, но никаких проблем использовать их порознь.
DHCP без NAT — любая домосеть с «белыми» адресами, которая автоматически раздаёт их.
NAT без DHCP — никаких проблем его сделать на обычном домашнем роутере.

Как действует NAT. Берём и корректируем в исходящем пакете какие-нибудь параметры вроде исходящего порта (чтобы узнать, чей пакет). Заодно меняем исходящий адрес на внешний адрес сети. Когда приходит ответ, восстанавливаем исходного абонента, меняем входящий адрес на адрес этого абонента и ретранслируем его во внутреннюю сеть.

Задача простого роутинга (который не NAT) — просто передать пакет дальше по цепочке, уменьшив TTL и определив по таблице маршрутизации, на какое из соединений надо его передавать.

?language=russian недавно исчезло и никто не знает, что дальше. Вероятно, теперь личные настройки пользователя перебивают то, что поставил автор.
Ссылка на время — #t=1h23m34s.

example.com — это домен = доменное имя
https://example.com — это уже URL, состоящий из…

• схемы URL’а (протокола, типа ресурса) https:
  
• и специфичных для протокола HTTP(s) вещей, к коим относятся
  
  • знак домена //
    
  • домен example.com

Когда мы пишем в браузере example.com/path, система понимает, что надо добавить схему и знак домена, но упаси бог такое писать в HTML — получится что-то типа http://local.example.net/example.com/path.

Это другая штука, имеющая опосредованное отношение к keep-alive. Это загрузка информации в несколько потоков.

Почему шесть соединений, а не пять — другой вопрос. Я бы предположил вот что. Браузер разобрал index.html и увидел там картинку. Создаём новое HTTP-соединение (нешифрованное) — два пинга спустя поехали данные. Задействуем имеющееся — один пинг спустя. С небольшим пингом браузер просто подумал, что быстрее будет вот так. А может, браузер просто туп и если мы укладываемся в количество соединений с одним сервером — создаём новые, да и всё.

А вот то, что все картинки в разных потоках — это верно. Если считать скорость сети «бесконечной», для каждой из них информация пойдёт с запозданием в два пинга. Работай мы в один поток — первая пришла бы с запозданием в 2 пинга, вторая в 3 пинга, третья в 4 пинга… А вот протоколы SPDY и HTTP/2 позволяют сказать: «Дай мне картинки А, Б и В»,— и они все, ОДНИМ СОЕДИНЕНИЕМ, придут с запозданием в два пинга.

Другими словами:
HTTP (все метки времени — когда они были посланы с клиента/приняты клиентом):
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запрос 1 (+1 пинг)
С: Ответ 1 (+2 пинга)
К: Запрос 2 (+2 пинга)
С: Ответ 2 (+3 пинга)

HTTP2:
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запросы 1, 2 (+1 пинг)
С: Ответы 1, 2 (+2 пинга)

На реальных «не очень быстрых» соединениях играют роль не только пинги, но и скорость передачи. Тогда картинки начнут появляться не по одной, а по восемь (или сколько там соединений) — это тоже может повлиять на впечатление от браузера. К тому же если случился затор на шлюзе локальной сети — тогда, если одно соединение забарахлит, другие что-то привезут. А если сеть не очень хорошо сконфигурирована — это ещё и ввосьмеро увеличит скорость передачи (реально в начале 2000-х качал в универе 10-мегабайтный драйвер за перемену в 100 потоков).

Я бы посоветовал сделать штук двадцать картинок — и тогда начнётся повторное использование имеющихся соединений.

Покажите конкретную картинку, я не нашёл.
Но в целом причина вот в чём. Часто камеры для простоты сохраняют картинку в стандартной ориентации, а реальный поворот аппарата записывают в EXIF. Одни браузеры эти EXIF’ы читают, другие нет.
Вообще сайт странный и в роли уменьшенных картинок — полноразмерные 1600×1200.

Parsing, разбор.

Для чего вообще солят хэши? Против сливов БД: если хэши ушли, по ним сложно восстановить пароли.
• Если при подозрении на слив мы можем перегенерировать ключи или объявить их просроченными;
• Если ключи держатся где угодно, только не в БД;
• Если ключи настолько длинны и случайны, что сложновато будет обратить алгоритм объединёнными хакерскими силами
— то зачем?

Впрочем, не забывайте, что хэшируя, вы автоматически снижаете криптостойкость вашего алгоритма до длины хэша. А может, проще изначально делать ключи такой длины?