00000001 + 00000001 = 00000011 alt text http://locobox.googlepages.com/red_x_round.png
Пора опровергнуть! ... «в какой-то момент» вы думали, что знаете что-то, и это оказалось неверным или не совсем правильным из-за неправильного представления о предмете.
Я начну с чрезвычайно очевидного примера (элементы, набравшие наибольшее количество голосов, будут наверху) :
Только 169,254 .0.0 / 16 зарезервировано для присвоения APIPA, когда ОС не может найти назначенный адрес для сетевого интерфейса ( читать: rfc3927 ).
***** Не путать с «Ошибки, допущенные системными администраторами»
Миф: Разрешение ICMP небезопасно.
Этот - мой главный объект неприязни, и это достаточно широко распространено для порождения значительных проблем в Интернете. Кроме удобной диагностики все мы знаем и любим, существует Путь Исследование MTU и другие вещи, которые повреждаются, когда ICMP заблокирован.
Хорошо, вот что-то, что я просто решил, что прежде ускользнул от меня, для каждого пакета, который Вы отправляете, кажется, что среднее число наверху составляет 38 байтов, это включает IP и Заголовок TCP (конечно, это значение предполагает, что все поля в заголовке TCP привыкли к макс., размеру заголовка IP, общая ценность т.е. никакие значения DSCP, и т.д., и т.д.), таким образом, для передачи говорят, что 2 МБ (с размерами пакета на уровне 64 КБ, увеличивающих пакеты в секунду [большие пакеты в секунду = меньшие издержки]), Вы смотрите на 1,2 КБ издержек, не очень, но это приравнивается к 6,78 МБ для каждых 10 ГБ, переданных и 607,8 МБ для каждого переданного 1 ТБ.
Я чувствую себя лучше теперь :D
Как насчет неправильного представления, которое можно разделить пропускную способность ссылки (на бит/с) 8 для точного моделирования, сколько байтов это передаст транзитом. Я всегда полагаюсь на 75% (макс.) восьми десятых частей скорости канала (т.е. для ссылки на 10 Гбайт/с я полагаюсь на 600 Мбайт/с макс.).
Я думаю самое большое неправильное представление, которое я вижу, то, что основанные на IP сети могут решить весь наш IT или технические потребности.
Самым большим примером, который я вижу этого, является VoIP. Это - телекоммуникационная инфраструктура, которая является так невероятно дорогой, интенсивно использующей ресурсы, и трудной справиться правильно. Уверенный развертывание работает... вид, но я уверен, что могли быть намного лучшие системы с выделенными протоколами / инфраструктура.
То, что Вам нужен перекрестный кабель для подключения 2 компьютеров с Gigabit Ethernet. Вы не делаете! Патч добивается цели!
Тип кабеля не имеет значения для сети, пока этому профессионально мешают. Это прибывает от администратора, задающегося вопросом, почему совершенно новые компьютеры все еще медленно получают доступ к Интернету с их адаптерами 100Base-T. Сетевым кабелем был CAT 3 IIRC.
Неправильное представление, что коммутируемая сеть Ethernet == защищенная сеть. Это не делает.
Помимо повсеместного присутствия arp-отравления инструментов как 'Cain & Abel' и их род, то, что таблица CAM испытает таймаут время от времени (значение по умолчанию 5 минут на Коммутаторе Cisco) и таким образом лавинно разошлет одноадресный трафик как концентратор, переводит в пакетную утечку и таким образом потенциальную утечку информации.
Можно изменить значение тайм-аута на управляемых коммутаторах для компенсации то, сколько лавинной рассылки Вы хотите позволить, но, учитывая, что это - часть того, как переключение Ethernet работает, Вы не можете смягчить его полностью.
Идея, что устройства выделенного оборудования всегда лучше, более надежны и с более высокими характеристиками, чем товар и/или аппаратные средства ПК - на практике с сегодняшними затратами.
Это в основном, чему Cisco хочет, чтобы Вы верили; уверенный, NPE в корпусе маршрутизатора только имеет процессор ARM на ~300 МГц, но он имеет все эти ASICs (Интегрированные каналы приложений) только для быстрой пакетной передачи, поисков маршрутизации FIB и так далее.
В то время как это может быть верно, и я обычно делаю одолжение с помощью собственного механизма того вида для маршрутизаторов и переключателей по ряду административных и СВЯЗАННЫХ С СВБР причин, факт - то, что в эру процессоров на 3 ГГц и 8 ГБ RAM, часто присутствие ASICs и CAM просто не имеет значения - ПК может все еще курить тот маршрутизатор. Несомненно, весь материал сделан в ЦП вместо offboarded к выделенному оборудованию и уверенный, это - все в процессах, подвергающихся разрушительным действиям среды планирования пространства пользователя, с которой спорят, в ОС общего назначения, но когда Вы имеете 20x мощность ЦП, иногда это не имеет значения - что это все еще выходит путь вперед, и намного более дешевый.
Я изучил это снова недавно при контакте с довольно высокопроизводительным ЯЩИКОМ ДЛЯ ПРОБНОЙ МОНЕТЫ, уступающим увеличивающимся пакетным загрузкам обработки в растущей среде VoIP (высокие пакеты в секунду наносят вред маршрутизаторам намного больше, чем полная пропускная способность по сути, и аудиопотоки VoIP состоят из очень большого объема очень небольших пакетов); брандмауэр Linux, который я настроил как временная мера для меж-VLAN, направляющего тем временем, унес ту вещь из воды.
Так же для BGP. Существуют все еще оживленные дебаты в мире Cisco о минимальных спецификациях маршрутизатора, должен был содержать один или несколько полных ракурсов BGP постоянно растущей таблицы маршрутизации IPv4, так как столько моделей маршрутизатора обычно способно к нему, были они не тесный на RAM. Ну, Вы знаете, Quagga и твердый сервер Linux с большим NIC и низким прерыванием, тонкие настройки ввода-вывода могут сделать чудеса.:-)
В среде Предприятия LAN многие люди все еще находятся под предположением, что маршрутизация между VLAN медленнее, чем переключение. С сегодняшними современными переключателями и переключение и маршрутизация обрабатываются в аппаратных средствах, которые могут обрабатывать/передавать эти пакеты на той же скорости.
Я ненавижу, когда сеть обвинена в чем-то с отстающим приложением.
Когда все работает кроме Вашего Outlook, прекратите обновлять билет до сетевой команды, заявляющей, что сеть снижается. Неосведомленные рабочие справочной службы являются отравой существования многих администраторов.
На практике...
802.11 А! = 54 Мбит/с, 802.11 А ~ 27 Мбит/с
802.11B! = 11 Мбит/с, 802.11B ~ 5 Мбит/с
802.11G! = 54 Мбит/с, 802.11G ~ 22 Мбит/с
James Gosling цитирует Peter Deutsch с кредитом на восемь ошибок распределенных вычислений:
По существу все, когда они сначала создают распределенное приложение, делают следующие восемь предположений. Все оказываются ложью в конечном счете, и все доставляют большие неприятности и болезненный полезный опыт.
- Сеть надежна
- Задержка является нулем
- Пропускная способность бесконечна
- Сеть защищена
- Топология не изменяется
- Существует один администратор
- Транспортные расходы являются нулем
- Сеть однородна
У меня есть они на стене моего куба, выходящего на прихожую. Иногда я чувствую, что спотыкаюсь за больше чем один из них в день.
Все Интернет-соединения создаются равные, иначе загружают скорость, единственная вещь, которая имеет значение
"Я просто узнал, каков T1, разве Вы не знаете, что мой кабель Comcast дома 6x быстрее, чем наше соединение на работе? Почему у нас нет этого здесь?"
Это больше не подходит, но это перешло к сути дела, где я буду скорее глотать главные продукты, чем пытаться объяснить SLA еще одному маркетинговому парню. (Хорошо, у меня был тот же вопрос, когда я был кустом поддержки рабочей станции, я допускаю его!)
Некоторые люди имеют религиозный, верит о позволенном и не позволенных IP-адресах. Вчера я видел в одном из ответов здесь, что 'IP-адреса, заканчивающиеся в.0 или.255, недопустимы', который является прост неправильный.
Другие все еще думают, что у нас есть A, B, C - измеренные подсети только, в то время как CIDR был управлением мир долгое время.
Некоторое заявление, что отключение ответов ICMP сделает мою рабочую станцию невидимой в ее сегменте LAN, который не верен. Можно все еще отправить запросы ARP, и в большинстве случаев машина отправит ответ ARP, хотя это имеет выполнение брандмауэра уровня IP.
Другие говорят, что частные подсети - 192.168.0.0/16 или 10.0.0.0/8 'не routable' - который является прост неправильный снова.
Люди действительно удивлены, когда они изучают, как насыщенность загрузки влияет на их скорости загрузки. Многое зависит от алгоритмов организации очередей на обоих концах узкого места, но в случае типичных подключений ADSL загрузка может значительно влиять на загрузку.
На забавной стороне: некоторые все еще думают, что "Интернетом является Серия Труб".
Неправильное представление, что использование беспроводного доступа в Интернет средств намного медленнее, потому что это показывает 54 МБ/с, тогда как использование соединения Ethernet показывает 100 МБ/с.
Само собой разумеется, это трудно объясняло пользователю, который был только скоростью локальной сети, и на самом деле интернет-скорость для сайта составляла только 8 Мбит/с / 900 кБайт/с.
Или альтернативно, пользователи, которые требуют Вас для предоставления широкополосного соединения, затем когда Вы говорите им беспроводную связь, что они используют, подключены к широкополосному подключению к Интернету, которое они восклицают "нет, Я имею в виду синий кабель!"
Нежно настраивая сокет с SO_LINGER
опция предотвратить TCP TIME_WAIT
состояние, потому что"TIME_WAIT
Вы знаете, таким образом, Вы знаете, старый и, Вы знаете, как, yucky".
Миф: Добавление большего количества пропускной способности к соединению будет всегда делать вещи быстрее.
Не так. Если Ваша ссылка не насыщается, и Вы пытаетесь получить данные от Китая до США, можно просто идти с такой скоростью, как Вы можете. Это занимает время (даже со скоростью света) для получения от США до Китая, и создание ссылки не пойдет быстрее, если у Вас только будет единственный поток данных, идущий между сайтами.
Это, если Совместный доступ к файлам SMB / NetBIOS не работает, что ничто иное не будет работать над сетью (включая просмотр WWW) и целой сетью, снижается.
Бывший веб-проводной педагог повернулся, системный администратор думал это, когда я был в средней школе. Я не знаю, была ли она разуверена вышеупомянутого понятия.
То, что домашняя точка беспроводного доступа (или два) может заменить проводную сеть в пользовательской среде. Несомненно, Ваше беспроводное соединение дома обрабатывает приблизительно до 5 ПК, но Вы пытаетесь заставить его иметь дело с двумя классами 30 детей вся попытка использовать ноутбуки для вхождения в систему домена Windows одновременно. Вам нужна управляемая система беспроводной связи или некоторые фиксированные проводные точки для обработки некоторых (хорошо, большинство) загрузки. И быстрое примечание управляемым продавцам системы беспроводной связи там: да, я уверен, что Ваша система имеет лучшую производительность, чем конкуренция, но это не бесконечно - существует только так много пропускной способности, которую можно сжать из ограниченного набора частот, доступных 802,11 беспроводной связи, Вы, канна' изменяет законы физики!
У меня есть несколько мифов, связанных с частными сетями (10.x.x.x, 192.168.x.x, и т.д.).
Оба этих мифа происходят от того же неправильного представления: тот частный дюйм/с является действительно частным и что они никогда не смешиваются с общедоступным дюйм/с. Я полагаю, что спецификация говорит только, что частный дюйм/с никогда не должен направляться в сети общего пользования. Таким образом, при попытке найти маршрут к некоторому случайному частному IP (предполагающий, что это не находится в Вашей собственной сети), то Вы не доберетесь нигде.
Но это не устраняет частного дюйм/с, появляющегося в выводе или результате некоторого запроса. Серверы внутренней почты, например, не имеют общедоступного IP-адреса, поэтому что другой IP-адрес они могут включать в Полученный - заголовком кроме их собственного?
Аналогично, большая установленная сеть может использовать различные частные сети среди их многочисленной LAN. Пакеты, которые проходят через их сеть, возьмут частного дюйм/с маршрутизаторов, даже если пакет в конечном счете сделает свой путь назад на сеть общего пользования. Таким образом traceroute может включать частный IP маршрутизатора в его выводе.
Это не будет работать - по крайней мере, не, по моему опыту. Скажем, Ваша работа использует 192.168.1.x сеть, и Вы используете того же дома (как типично для потребительских маршрутизаторов). Вы устанавливаете соединение VPN от своего домашнего ПК для работы. В какой-то момент Вы хотите отправить задание печати на принтер на работе, IP-адрес которой 192.168.1.10. Ваш домашний ПК выглядит в своей таблице маршрутизации для выяснения, куда отправить тот пакет. Который LAN должна получить его: Ваша домашняя LAN или Ваша работа LAN? Ответ: не знать. Возможно, этот, возможно, что один. Один из них получит его, но это, вероятно, зависит от Вашего программного обеспечения OS и VPN для различения, какой получает приоритет. Если это похоже на программное обеспечение VPN, у меня был опыт с, Ваша домашняя LAN получит его и если не будет устройства в 192.168.1.10, то пакет будет отброшен в конечном счете.
Решение: при использовании VPN удостоверьтесь, что обе LAN использует различные сетевые пространства.
Миф: Удвоение бит/с ссылки удваивает полезную пропускную способность.
Как со многими мифами это может быть верно при некоторых ограниченных обстоятельствах, но это игнорирует задержку ссылки и пределы производительности оконечных систем и протоколов.
Увеличение бит/с уменьшает время, которое требуется, чтобы система получила данные на ссылку, это не заставляет данные пройти ссылка быстрее. Время для запуска первого бита, который прибудет в другой конец, совпадает с, прежде, но задержка до последнего бита прибывает, уменьшается.
То дублирование MAC-адреса не возможно. Это, это только что довольно чинило вряд ли.
Тот "Мбайт/с" и "Мбит/с" являются взаимозаменяемыми. Даже если я мог бы контекстуально различить это, 'миллибиты' не являются допустимой единицей измерения, существует все еще фактор 8 различий между двумя.
И даже не запускайте меня на mebibits.
Тот материал выполнения в "аппаратных средствах" всегда лучше работает, чем выполнение его в "программном обеспечении".
(который приводит к очевидному вопросу того, где каждый разграничивает между этими двумя так или иначе, или если существует даже хорошее различие вообще?)