Я постараюсь максимально объективно сравнить два языка. В конечном итоге, выбор платформы, стиля и языка – не определяющий фактор успеха. Главное, чтобы руки разработчика не повторяли форму интеграла. Ведь язык лишь инструмент, а инструмент, как известно, продолжение рук.

Начнем.

WEB развивается уже второй десяток лет. Время статичных HTML-страниц кануло в истории, на смену которому пришел абстрактный стандарт WEB2, главное требование которого – взаимодействие с пользователем. Спорить, правильно ли это, конечно, можно, только в таком случае появляется вполне резонный вопрос: зачем читать эту статью, если она о средствах создания подобных сервисов?

Порог вхождения.

Традиционно для сравнительного анализа языков в первую очередь используют удобство синтаксиса, скорость работы и возможности.

Такой подход логичен для выбора собственного. А вот с точки зрения работодателя, качества самого программиста значительно важнее.

PHP считается простым языком. Это не удивительно: от открытия учебника до первого “HelloWorld-a” проходит не больше 5 минут. С одной стороны это хорошо. Но подводных камней не мало.

Потратив неделю на изучение PHP, можно научиться базовым приемам ввода-вывода, примитивной выборке из БД и парочке других алгоритмов обработки информации. С усложнением задач появляется соблазн изобретать “велосипеды” и “костыли” на основе старых знаний, делая код нечитабельным, уничтожая возможность дальнейшей поддержки на корню.

Работа с таким “кодером” в команде, или еще хуже, поддержка проекта, написанного им, превращается в будни школьного учителя. Естественно, это утверждение относится не ко всем, но такая проблема существует.

Что касается Java, порог вхождения очень высокий. Вместо “Установка LAMP под Ubuntu” и “Скачать самоучитель PHP“, необходимо вникнуть в сервлеты, взаимодействие между ними, jsp, научиться работе с каким-нибудь фреймворком.

Плюс ООП, который в Java обязателен. Если проводить аналогию, начало работы сравнимо с высшей математикой в ВУЗ-е: всех неспособных отправить на службу родине.

Подобный подход к оценке языка не панацея. Достаточно много серьезных проектов, написанных на PHP. Более того, на данный момент в сфере WEB-разработок он доминирует.

Синтаксис и код.

Одна из обсуждаемых проблем Java – длиннейшие названия классов и стандартных методов. Чего только стоит “System.out.println()” оного вместо “echo” на PHP. Конечно, это легко решается “import-ом” в начале документа или выбором современной IDE, в которой достаточно написать первую букву метода или поля, как появится возможность выбора нужного из списка. Тем не менее, отрицать впечатляющий объем кода на Java – предвзято.

PHP тоже не идеален. Взять к примеру обязательный знак доллара перед переменной. Конечно, рациональное зерно различия между обозначениями переменных и методами(функциями) присутствует. Лично у меня это вызывает жуткую головную боль. В первую очередь от созерцания самого знака. Плюс, я так и не сумел привить у себя
привычки ставить доллар перед каждой переменной. Слишком меркантильно, что-ли…

Что касается кода, я думаю мало кто станет спорить, что серьезный проект == серьезная работа в команде. А работа в команде требует годного, понятного кода, качественную документацию, и возможность эффективно распределить работу.

Здесь принудительное ООП Java и Javadoc для документации дают ощутимый прирост в копилке аргументов “За Java”.

В PHP эти возможности так же есть. Сравнительно недавно я узнал о аналогах Javadoc в PHP- phpdoc/PhpDocumentor.

С известных версий PHP поддерживает объектный подход(ООП). Правда он смешанный, и соблазн написать простую функцию без обертки очень большой.

Техническая площадка.

С кодом мы разобрались. А вот что касается хостинга, Java в проигрыше. PHP-хостинг распространен и он дешевле.

Правда под вопросом, стоит ли экономить на хостинге, если проект серьезный? Тем не менее, то, что заменить техническую основу проекта на PHP проще – факт.

Другой вопрос, если проект используется в интрасети. Стоимость хостинга отпадает. И программирование на стороне клиента дает плюс в сторону Java. Интеграция апплетов на нем в сети интернет потерпела крах, так как для запуска они требуют имплементатор на локалхосте. Но когда клиенты доступны физически, проблем нет.

Единая платформа, без связки разных языков – очевидный плюс.

Вместо заключения.

Я постарался не затрагивать сравнения технических характеристик языков. Такой информации в интернете полно. Так же считаю, что качество разработки значительно важнее. Язык создан для человека, а не для процессора. Для второго есть ассемблер.

Претензий на объективность у меня нет. Я попытался, насколько успешно- не знаю. Буду рад аргументированной критике.

Под конец повторюсь: все в руках разработчика, язык лишь инструмент. Профессионал и пальцем болт закрутит.

В этой статье я хочу описать свой опыт работы на фрилансе.

Что за фриланс?

Может быть есть люди, которые не знают, что такое фриланс? “Freelance” буквально переводится как “внештатно”, соответственно “freelancer” — “внештатный сотрудник”. Обычно это подразумевает поиск заказов через интернет, выполнение их дома за компьютером (хотя некоторые ловко трудятся во время основной работы ) и оплату выполненной работы через интернет. Существуют специальные сайты — фриланс-биржы — на которых происходит общение заказчиков, имеющих какие-либо задания, и исполнителей, готовых эти задания выполнить.

А зачем это нужно?

Наверное каждый программист замечал, что работая постоянно, у него не хватает времени заниматься какими-то своими проектами. А различные идеи периодически приходят, и думаешь: “Вот было бы время, обязательно бы это реализовал”. Да и на работе бывают времена, что приходится заниматься неинтересными делами. Тем более в мои планы не входило всю жизнь работать “на дядю”, рано или поздно пришлось бы уходить на вольные хлеба, и во время особо скучного периода на тогдашней постоянной работе я и решил это сделать.

Для начала я решил закрепиться на фриланс-биржах, чтобы в случае чего всегда можно было бы заработать денег, невзирая на текущую жизненную ситуацию, был бы под рукой ноутбук и интернет. К тому же всегда есть из чего выбрать: захотел делать сайт — вперед, захотел написать скрипт — флаг в руки, надоел язык программирования — меняй, никто не запрещает.

Биржи? Биржи. Биржи…

Фриланс-бирж существует множество, как российских, так и зарубежных, в итоге я зарегистрировался на трех — freelancer.com, free-lance.ru и weblancer.net.

freelancer.com я выбрал, так как прочитал довольно интересную статью, описывающую прелесть работы на ней. Здесь я решил представиться веб-студией, по идее такой подход вызывает больше доверия у заказчиков, придумал “конторе” название, сделал простенький логотип, зарегистрировался и начал осматриваться.
Если описать в общем, сайт представляет собой типичную фриланс-биржу – страницы разделов по возможным IT-работам, например создание сайтов “под ключ”, создание дизайнов, работа с различными CMS, написание скриптов, системное администрирование и т.д. Заказчик выбирает нужный ему раздел, создает проект, на который откликаются заинтересовавшиеся фрилансеры.

На freelancer.com ищут заказы очень много фрилансеров, среди которых немало выходцев из Азии. Качество работы большинства этих товарищей, как и знание английского языка, оставляет желать лучшего (кто не слышал про программистов-индусов ), но они берут ценами, иногда демпинг с их стороны вызывает даже не недоумение, а смех. Вполне реально найти “исполнителя” на сложный специфичный портал за сумму например 100$ и сроком исполнения 3 дня. И это предложение еще могут перебить!
Естественно, есть и мастера своего дела, с высочайшим профессионализмом, большим опытом и умением подойти к клиенту.

К сожалению, на этом сайте мне так и не удалось получить ни одного заказа, наверное из-за окончательной переориентации на отечественный рынок. Свою роль сыграли и не очень удовлетворительный английский, и разница во времени с многими заказчиками.

Российские биржи, на которых я зарегистрировался — free-lance.ru и weblancer.net. free-lance.ru – самая известная из отечественных, держит первенство по количеству проектов и активных фрилансеров. Содержит много платных услуг, жизнь без которых затруднена, например не имея pro-аккаунта можно подавать только три заявки на понравившиеся проекты в сутки. Но таким ограничением страдают все биржи, которые я встречал. Впрочем это мне не очень мешало, с первых дней мне хотелось насладится преимуществом выбора интересных заданий. К сожалению, появлялись они не так часто, как хотелось бы, а при подаче заявки меня всегда обходили более опытные исполнители, с отзывами и более долгим временем нахождения на сайте.

Про это стоит упомянуть подробнее. Практически все заказчики смотрят на количество отзывов, имеющихся у фрилансера, которые оставили прошлые работодатели. Хорошо выполнил работу — написали положительный, плохо, не выполнил или исчез — отритцательный. Наверное уже с 3-мя отритцательными отзывами лучше завести новый аккаунт, так же как и если первый отзыв — негативный. То же самое и с временем, прошедшим после регистрации, некоторые не доверяют людям, у которых оно меньше месяца. Сначала порой приходилось работать и за еду просто за отзыв.

Когда подходящий проект найден, встает задача, чтобы заказчик выбрал именно вас. Тут у каждого свой подход, кто-то просто называет цену и оставляет сообщение “пишите в личку”, кто-то строчит простыни текста, в подробностях расписывая все свои предыдущие достижения, кто-то выбирает нечто среднее. По-моему стоит писать, какие подобные задания уже приходилось выполнять и по-возможности дать понять, что понимаешь задание и чуть ли не начал его делать.

Но вот первый проект получен, наконец-то меня выбрали исполнителем! Обсудив все детали задания, пора начинать работать! Но, что все не так просто, стало понятно через пару проектов. ТЗ и детали нужно обговаривать ОЧЕНЬ подробно, выясняя все до последних мелочей, иначе дорабатывать и изменять казалось бы незначительные и неважные детали и наводить красоту по вкусу заказчика можно вечно, либо, неправильно поняв суть задания, вообще выбрать неверный путь решения задачи. Был случай, когда недели две работы потратились впустую из-за непонимания и несогласованности между мной и заказчиком, в итоге я потерял деньги, а клиент время, хорошо, что в результате разошлись мирно, без написания отритцательных отзывов друг другу.

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

Не биржей единой

Поиск заказов не ограничивается только биржами.
У многих заказчиков постоянно появляются новые задания, и если ты хорошо выполнил одно, наверняка следующее также достанется тебе, плюс этот заказчик будет рекомендовать тебя своим знакомым, у которых возникла необходимость в привлечении стороннего сотрудника.
Постепенно знакомые и бывшие коллеги узнают о твоей работе на фрилансе и заказы начинают приходить через них.
Через некоторое время я перестал заходить на биржи и выполнял только подобные задания, потому что они скорее всего будут интересные, с заказчиком уже сложились более-менее неплохие отношения, почти нет недоверия и настороженности, как у тебя, что прокатят с деньгами, так и у него, что работа не будет выполнена.

Также не стоит забывать про свои задумки, отводить какое-то время на них, даже если пока ни одна из них еще не приносит какой-либо ощутимой отдачи, ведь это только пока Главное, что для них находится время.

Ожидания и реальность

Для кого-то работать дома в кайф, но я знал, что постоянно находиться в четырех стенах мне будет затруднительно, однако утешал себя мыслью, что можно будет выйти, например, в парк и работать там. Но на практике зарядки ноутбука хватает не намного времени, у нетбука маленький экран, а на лавке в парке с этими девайсами неудобно сидеть. Если еще вспомнить, каким жарким было лето 2010, то можно понять, как я завидовал людям, сидящим в прохладных офисах с кондиционерами, тогда как дома был только плохо спасающий от этого ада вентилятор.

Когда я начинал свой путь по дороге фриланса, то не строил иллюзий, что в первый же день клиенты выстроятся в очередь, но все же было неожиданно, что уцепиться за первый проект удалось только недели через две. Эта ситуация получилась и из-за того, что, как упоминалось ранее, я не откликался на неинтересные заявки, а ждал чего-то более привлекательного. Зато проект оказался интересным, довольно денежным и с хорошим заказчиком, которому впоследствии я выполнил еще несколько заданий.

По поводу рабочего времени происходило примерно так, как я и думал: то работы нет, то работать приходится по ночам, не говоря уже про выходные. Если на постоянной работе знаешь, что в субботу-воскресенье отдыхаешь, на фрилансе все смешивается и иногда удивляешься радости друзей о том, что завтра выходной.
Можно безболезненно с утра покататься на велосипеде, посреди рабочего дня прерваться, например, на гантели или прогулку (это если нет срочной работы, конечно ).

Волнующий денежный вопрос. Честно говоря, когда я уходил на фриланс, то ожидал, что буду зарабатывать больше. Очень сложно назвать среднюю сумму заработка, в первые месяцы у меня выходило не более 10-15 тысяч ежемесячно.

Итого

Что же в итоге? Не жалею ли я о том, что ушел с постоянной работы на фриланс? Нет.
Сейчас я частично (5 часов в день) работаю в офисе на постоянной работе, которая нашла меня через фриланс, остальное время практически полностью посвящаю своим делам, лишь иногда откликаясь на работу от постоянных заказчиков, приобретенных на фрилансе.

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

Я web-программист, проработал уже достаточное время на этой должности и, честно говоря, порядком подустал. К тому же я не вижу каких-то особых перспектив, к которым мне хотелось бы стремиться.

Нет, они, конечно, есть. Программист перерастает в руководителя группы, потом в руководителя отдела, возможно, потом еще в кого-то, потом «потолок». Кого-то может такая ситуация устраивает, но она не для меня.

И я решил, что нужно открывать свое дело, где ты работаешь только на себя, получаешь столько денег, сколько заработал сам. Вот здесь открываются огромные перспективы. Они мне интересны, хочется стремиться к поставленным для себя целям.

Для начала я посоветовался со своими друзьями, перечитал не мало статей про различные виды заработка для программиста. И вот какие выводы я для себя сделал:

Где web-программист может проявить себя самостоятельно?

• Фриланс.

Возможно, стоило бы попробовать, но все-таки по рассказам знакомых фрилансеров больших денег там не заработаешь. Особенно первое время придется усиленно экономить. Да и все же это не совсем работа на себя, а работа на заказчика.

• Web-студия.

Для ее открытия нужен какой-то стартовый капитал, которого у меня нет. Кроме того, большие риски, что вложенные на начальном этапе средства так и не окупятся. Опять же в этом варианте присутствуют заказчики, на которых тебе придется вкалывать.

• Интернет-магазин.

На данный момент самый подходящий для меня вариант. Его я и выбрал.

Почему я хочу открыть интернет-магазин?

Устал от работы на дядю, надоели начальники, которые вечно самоутверждаются за счет своих подчиненных.

Ситуацию можно описать известной фразой: «Я начальник, ты дурак, ты начальник, я дурак». Причем как-то получается так, что «дураком» ты становишься автоматически, независимо от объема твоих знаний, опыта и т.д. Начальник все равно знает больше, чем ты, только он может принять единственно верные решения.

Кто-то может сказать: «Все правильно, он прошел свой путь, начиная простым программистом, набрался опыта, поднялся по карьерной лестнице и, конечно же, он будет обладать большими знаниями».

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

Найдется ли такой программист, который никогда не попадал на такой диалог?
– Сколько займет времени, чтобы это сделать?
– Думаю, что где-то полдня нужно будет.
– Почему так долго? Здесь же просто кнопку поставить.

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

В ответ на твои объяснения ты получаешь примерно следующую фразу: «Ну не знаю, мне кажется, что все равно это очень долго».

Кроме того, много денег при работе на кого-то не заработаешь. Все равно есть потолок.

Доход от интернет-магазина будет зависеть только от тебя и от его развития. Теоретически предела доходам здесь нет.

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

На мой взгляд, каждому коллективу присуща определенная доля лживости. Вроде как все говорят: «Мы вместе, мы одна команда». Все друг другу улыбаются, все друзья, все классно. Однако, это только на поверхности.

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

Коллективу часто приходится объяснять начальству, почему не выдерживаются сроки в том или ином проекте. А начальству важно знать, кто конкретно тормозит проект. В таких ситуациях приходится закладывать кого-то из своих «друзей».

Когда в коллективе решают, кому конкретно доверить очередной проект, тут то и выясняется, чьи знания и опыт ценят, а чьи нет.

Но ведь на поверхности то все равны, все сотрудники одинаково ценятся.

В общем эта как-бы «дружба» не для меня. Чисто с психологической точки зрения я бы себя чувствовал спокойнее, занимаясь своим делом и не отвлекаясь на всякие закулисные склоки.

А что продавать?

Вот это очень трудный и самый важный вопрос на начальном этапе. На данный момент в интернете можно купить почти все. Конкуренты есть везде. Но выбирать что-то нужно.

Я для себя определил следующие критерии моего будущего товара:

• Он должен быть легким, чтобы не было проблем при доставке.
• Его стоимость не должна быть очень низкой. Большого объема заказов в первое время не предвидится, поэтому даже один заказ должен приносить более менее приличную сумму (не 1 рубль, а, скажем, 200).
• Он должен быть приспособлен для интернета. Например, продавать продукты питания через интернет, на мой взгляд, не самая лучшая идея. Все-таки некоторые товары люди хотят «пощупать», когда его выбирают.
• В идеале этот товар должен быть интересен мне, чтобы я мог иметь какое-то мнение по нему. Тогда я бы мог составлять описания к товарам, а это поможет продвижению в поисковиках.

Осталось теперь найти товар, удовлетворяющий этим моим критериям. Пока я нахожусь в поиске.

Под эти пункты очень подходят книги, но здесь очень высока конкуренция, поэтому их я не рассматриваю.

Определиться с товаром — это одна проблема. Решив ее, придется еще найти поставщиков, которые готовы этот товар поставлять. Кроме того, т.к. у меня нет никакого начального капитала, то закупать товар оптом я не смогу. Поэтому нужно найти поставщика, который будет готов поставлять товар по факту заказа. Т.е. мне представляется следующая схема: мне пришел заказ, я еду к поставщику, забираю у него товар, доставляю товар клиенту.

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

Итак, товар выбран, поставщик найден. Чем мой магазин будет отличаться от других? Нужно придумать уникальное торговое предложение (УТП). Возможно, в моем магазине цены будут ниже, чем у конкурентов, возможно, что-то еще, но клиента нужно будет чем-то зацепить, чтобы, совершив один раз покупку у меня, он вернулся ко мне же за следующей.

На эту тему я пока даже не думаю, сначала надо определиться с товаром.

Планы

Перед открытием магазина я зарегистрирую ИП. Скорее всего воспользуюсь услугами какого-нибудь агентства, но, похоже, что даже в этом случае придется помотаться по всяким гос. учреждениям. Ну а что делать, без этого в нашей стране никуда.

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

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

Да, еще планирую обзавестись прямым номером на свой мобильный. Оставлять 10-значный номер телефона на сайте, как мне кажется, будет выглядеть не серьезно.

Доставкой буду заниматься первое время сам. Придется как-то совмещать с текущей работой, но это, надеюсь, продлится не долго, т.к. за первые 1-2 месяца станет более менее понятно, что получится из магазина в итоге.

Если заказов будет не мало, то возьму отпуск, может даже за свой счет.

Моя первоначальная цель — достичь дохода от магазина, равного половине моей текущей зарплаты. Если добьюсь этого, то планирую уволиться, а часть денег зарабатывать на фрилансе. В итоге мой месячный доход будет равен текущему доходу на постоянной работе.

Давно хочу изучить язык программирования python и фреймворк django. Как раз мой магазин поможет мне в этом. Даже, если ничего путного не выйдет, то, как минимум, будет опыт программирования на python.

Ну вот вроде и все. Я хотел в этой статье поделиться своими мыслями и планами по поводу открытия своего интернет-магазина. Как только приступлю к реализации этих планов, поделюсь полученным опытом в следующей статье.

Жду любых ваших мнений в комментариях.

Также интересно было бы узнать мнение программистов, которые уже прошли путь открытия своего бизнеса (не обязательно интернет-магазин).

Все это из области фантастики. Каждый из нас допускает ошибки, поэтому нам нужно их как-то отлавливать.

Если ошибка синтаксическая, то в большинстве случаев на это укажет компилятор. Но, если ошибка логическая, то часто программист сам не в состоянии определить ее.

Конечно, если программа не сложная, то можно самостоятельно, не прибегая ни к каким дополнительным средствам, выявить ошибку.

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

В этой статье рассказывается об отладке программ, написанных на языке C, в командной строке Linux с использованием утилиты GDB.

Многие программисты, которые с успехом разрабатывали свои приложения на языках C/C++ для Windows, после перехода к разработке программ на том же языке, но под ОС семейства Linux с удивлением обнаруживают, что отсутствует возможность той отладки, которой они пользовались в редакторах при написании программ для Windows.

Однако, такая возможность есть и это отладчик GDB.

Как следует из документации к этой утилите «цель отладчика GDB – это позволить вам увидеть, что происходит внутри программы пока она выполняется, или что программа делает в момент ее краха.».

На момент написания этой статьи отладчик GDB работает с программами, написанными на языках C, C++, Modula-2. Мы будем отлаживать приложение, написанное на языке C.

Давайте начнем с приведения кода программы, которая в качестве аргумента принимает число и высчитывает факториал этого числа при помощи рекурсии. Ее мы и будем отлаживать.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
int fact(int num)
{
    if(num <= 1)
    {
      return 1;
    }
 
    return num * fact(num - 1);
}
 
int main(int argc, char **argv)
{
  int a = atoi(argv[1]);
  printf("%d! = %d\n", a, fact(a));
 
  return 0;
}

Теперь скомпилируем ее с включением отладочной информации. Для этого в командной строке заходим в директорию, в которой лежит наш файл с расширением .c и выполняем команду:

g++ -g fact.c -o fact

Опция -g сообщает компилятору о том, что в программу нужно включить отладочную информацию, которой и воспользуется отладчик GDB.

Опция -o сообщает компилятору g++ путь до исполняемого файла. Если ее не указать, то, по умолчанию, компилятор создаст исполняемый файл в той же директории, где находится наша программа, и назовет его a.out.

Теперь запустим нашу программу в режиме отладки:

gdb -q fact

Опцию -q можно не указывать, она используется лишь для того, чтобы при первом заходе в отладчик не выводилась информация о версии, лицензионное соглашение и т.д.

Итак, мы запустили отладчик. Теперь мы можем выполнять его команды.

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

(gdb) list 10
5       int fact(int num)
6       {
7           if(num <= 1)
8           {
9             return 1;
10          }
11
12          return num * fact(num - 1);
13      }

Также можно передать название функции, после чего будет выведен код, окружающий эту функцию.

(gdb) list fact
1       #include <stdio.h>
2       #include <stdlib.h>
3       #include <unistd.h>
4
5       int fact(int num)
6       {
7           if(num <= 1)
8           {
9             return 1;
10          }

Давайте запустим теперь выполнение программы под отладчиком. Это можно сделать одной из двух команд: run или start.

Отличие между этими двумя командами в том, что, вызвав команду start, отладчик останавливается на входе в функцию main, а команда run выполняется до тех пор, пока не наткнется на точку останова (о них чуть позднее).

Обе эти команды принимают в качестве параметра аргументы программы так же, как если бы программа запускалась из командной строки.

Итак, запустим программу на выполнение в режиме отладки:

(gdb) start 4
Temporary breakpoint 2 at 0x8048556: file fact.c, line 17.
Temporary breakpoint 2, main (argc=2, argv=0xbffffa24) at fact.c:17
17        int a = atoi(argv[1]);

Как видим, отладчик остановился сразу же на входе в функцию main, а также вывел код и номер строки, перед которой остановился.

Используя команду print, мы можем вывести значения переменных и выражений. Посмотрим какие входные аргументы приняла наша программа:

(gdb) print argv[0]
$1 = 0xbffffb41 "/home/user/cpp/fact"
(gdb) print argv[1]
$2 = 0xbffffb5f "4"

В нулевом элементе массива argv содержится путь до выполняемой программы, а в первом элементе наш переданный аргумент — 4.

Для того, чтобы перейти на следующую строку, необходимо выполнить команду step или next.

Используя эти команды, можно передвигаться по программе. Отличие этих команд состоит в том, что step будет заходить внутрь функции каждый раз, когда ее встретит, а next пойдет дальше.

Перейдем к следующей строке:

(gdb) step
18        printf("%d! = %d\n", a, fact(a));

Мы сделали один шаг и остановились перед 18-ой строкой.

Пойдем дальше:

(gdb) step
fact (num=4) at fact.c:7
7           if(num <= 1)

Мы вошли в функцию fact с входным параметром 4 и оказались перед 7-ой строкой.

Т.к. мы имеем дело с рекурсией, то, вероятно, нам будет интересно значение переменной num, которое будет изменяться при каждом рекурсивном входе в функцию fact.

Добавим в процесс отладки слежение за переменной num. Для этого существует команда display, которой необходимо передать название переменной. В нашем случае это будет переменная num.

Выполним команду display и перейдем на один шаг вперед:

(gdb) display num
1: num = 4
(gdb) step
12          return num * fact(num - 1);
1: num = 4

Как видим, теперь при каждой остановке программы отладчик GDB сообщает нам значение переменной num.

Сейчас мы находимся перед рекурсивным входом в функцию fact. Заходим в нее и делаем еще один шаг вперед:

(gdb) step
fact (num=3) at fact.c:7
7           if(num <= 1)
1: num = 3
(gdb) step
12          return num * fact(num - 1);
1: num = 3

Отладчик сообщает нам значение переменной num, которое уже равно 3. Сейчас мы снова находимся перед заходом в функцию fact.

Скорее всего, не имеет смысла каждый раз проделывать эти шаги в функции fact. Нам достаточно было бы отслеживать какие значения принимает переменная num в 12-ой строке, т.к. в этой строке происходит рекурсивный вызов функции, а также возвращается результат ее выполнения.

Для того, чтобы добиться поставленных целей, мы можем поставить точки останова. Наша рассматриваемая программа достаточно не велика, поэтому мы могли бы пройти по каждой строке, используя отладчик, вплоть до завершения программы.

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

Расставив точки останова, отладчик может «перепрыгивать» к строкам, на которых они поставлены, минуя весь остальной код. Для этого можно использовать команду continue, которая продолжает выполнение программы до тех пор, пока не встретится точка останова. Если их нет, то программа выполнится до конца.

Итак, давайте поставим точку останова в строке 12 и выполним команду continue, чтобы продолжить программу до тех пор, пока не наткнемся на строку 12:

(gdb) break 12
Breakpoint 2 at 0x8048529: file fact.c, line 12.
(gdb) continue
Continuing.
 
Breakpoint 2, fact (num=2) at fact.c:12
12          return num * fact(num - 1);
1: num = 2

Мы прошли все шаги, которые до этого проделывали командой step. Теперь, каждый раз выполняя команду continue мы будем оказываться на 12-ой строке, а, благодаря выполненной ранее команде display, мы сможем наблюдать как изменяется значение переменной num на каждом шаге.

Есть и другой способ следить за изменением переменной в ходе работы программы с использованием команды watch. В отличие от команды display, эта команда при каждом изменении переменной, переданной в качестве параметра, будет останавливать выполнение программы и выводить старое и новое значение переменной.

Обе команды display и watch могут в качестве параметра принимать не только переменные, но и выражения.

Продолжим выполнение программы:

(gdb) continue
Continuing.
4! = 24
 
Program exited normally.

Отладчик показал вывод нашей программы, а именно подсчитанный факториал от 4. Последняя строка в выводе отладчика сообщает, что программа завершилась. Отладчик также вывел бы код возврата программы в восьмеричной форме, если бы программа возвращала число, отличное от нуля.

Очень полезной может оказаться команда set variable, которая позволяет изменять значение переменной по ходу выполнения программы:

user@linux-hn2z:~/cpp/> gdb -q fact
(gdb) start 4
Temporary breakpoint 1 at 0x8048556: file fact.c, line 17.
Starting program: /home/user/cpp/fact 4
 
Temporary breakpoint 1, main (argc=2, argv=0xbfffef84) at fact.c:17
17        int a = atoi(argv[1]);
(gdb) step
18        printf("%d! = %d\n", a, fact(a));
(gdb) set variable a=10
(gdb) c
Continuing.
10! = 3628800

В этом примере мы запустили программу с входным параметром — 4, но по ходу выполнения программы мы заменили этот параметр на 10, и программа подсчитала факториал от 10.

Команду set variable можно применять, например, когда вы на каком-то шаге обнаружили, что программа ведет себя не верно, но путем изменения значения переменной можно исправить ситуацию и посмотреть как программа будет вести себя дальше.

В настоящей статье описаны далеко не все возможности отладчика GDB. За более подробными руководствами обращайтесь к документации по утилите, кроме того, находясь в отладчике, можно вывести список всех команд и описаний к ним, воспользовавшись командой help.

На этом все. Удачной отладки.

Очень часто на собеседованиях приходится слышать вопрос:

Что происходит, когда пользователь в адресной строке браузера, вводит адрес сайта и нажимает enter?

Ответ должен звучать примерно так:

Отправляется HTTP-запрос по протоколу TCP/IP на сервер, на котором расположен сайт. Далее программа web-сервер (обычно Apache, nginx или lighttpd) принимает этот запрос и в случае, если вызываемый файл — это обычный HTML, то посылает в ответ браузеру свой HTTP-ответ, в котором содержится этот HTML.

Если вызываемый файл — это скрипт, например PHP, то сначала передается управление этому скрипту, который после всех своих операций на выход подает HTML, который web-сервер отсылает HTTP-ответом обратно браузеру.

Получив от сервера HTML, браузер его преобразовывает в удобочитаемый вид согласно стандарту W3C, отправляет дополнительные запросы для отображения изображений или flash и пользователь видит содержимое сайта — текст, картинки, flash и т.д.

В этой статье я дам подробное описание HTTP-запросов и параметров, которые могут в нем содержаться. Потом представлю реализацию обмена HTTP-запросами посредством языка PHP — мы напишем простой прокси-сервер, при обращении к которому он возвращает браузеру страницу сайта, адрес которого был указан в GET-параметре.

Для тех, кто не знает, браузеры обмениваются с серверами HTTP-запросами. Именно за счет этого мы можем переходить по ссылкам, отправлять данные формы и получать на эти действия ответы от сервера.

Кстати, очень полезными бывают утилиты, отображающие HTTP-запросы, которые отправляет и получает браузер. Я пользуюсь для этого браузером Mozilla Firefox и утилитой HttpFox.

Итак, давайте рассмотрим пример.

Введем в адресную строку браузера http://example.com и нажмем enter.

В результате браузер отправит HTTP-запрос вида:

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

В приведенном примере браузер хочет получить индексную страницу сайта example.com.

Получив запрос от браузера, web-сервер проверяет в своих настройках что является индексным файлом для сайта example.com.

Если это обычный HTML, например файл index.html, то просто возвращается его содержимое.

При запросе индексной страницы сайта http://example.com браузер получает от сервера следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8 

<HTML>
<HEAD>
  <TITLE>Example Web Page</TITLE>
</HEAD>
<body>
<p>You have reached this web page by typing "example.com",
"example.net",
  or "example.org" into your web browser.</p>
<p>These domain names are reserved for use in documentation and are not available
  for registration. See <a href="http://www.rfc-editor.org/rfc/rfc2606.txt">RFC
  2606</a>, Section 3.</p>
</BODY>
</HTML>

Обратите внимание на 2 перевода строки в ответе сервера. Они являются разделением между параметрами ответа и телом сообщения, содержащего html, который и отображается в окне браузера.

В случае какого-либо скрипта, сначала происходит выполнение этого скрипта, который возвращает web-серверу HTML. Web-сервер в свою очередь отправляет этот HTML браузеру.

Представим себе, что индексной страницей сайта example.com является файл index.php. Web-сервер в этом случае, получив запрос от браузера, сначала передает управление интерпретатору PHP, который выполняет код, содержащийся в этом файле.

Например, в файле index.php содержался бы следующий код:

1
2
3
4
5
6
7
8
9
10

<?php
	if($GET['category'] == 1)
	{
		echo "<p>This is a category of example.com</p>";
	}
	else
	{
		echo "<p>This is a main page of example.com</p>";
	}
?>

Если ввести в адресной строке браузера http://example.com?category=1 и нажать enter, то браузер отправит примерно следующий запрос:

GET /index.php?category=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

От сервера придет в этом случае следующий ответ:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 39
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a category of example.com<p>

Однако, если в адресной строке браузера ввести http://example.com/index.php, то ответ сервера будет таким:

HTTP/1.x 200 OK
Date: Tue, 21 Jul 2009 17:09:54 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT
Etag: "b80f4-1b6-80bfd280"
Accept-Ranges: bytes
Content-Length: 40
Connection: close
Content-Type: text/html; charset=UTF-8 

<p>This is a main page of example.com</p>

С телом запроса думаю все понятно — в нем содержится html, который и отражается в окне браузера. Давайте теперь разберем что же хранится в параметрах запроса браузера и ответа сервера.

Начнем с HTTP-запроса, который отправляет браузер.

Первая строка – это строка запроса. Она содержит следующие поля, разделенные через пробел:

• Метод запроса. Может принимать значения: OPTIONS, GET, HEAD, POST, DELETE, TRACE. Целью настоящей статьи не является рассмотрение всех методов. Нам будет достаточно метода GET. Если вы хотите получить описание каждого из методов, то советую обратится к документу RFC 2068
• Запрашиваемый URI — путь до запрашиваемого ресурса на сервере. Если запрашивается главная страница сайта, то указывается путь до корневого каталога сервера – «/».
• Версия HTTP-протокола. В этом поле содержится строка вида: «HTTP/1.1». О различных версиях протокола HTTP также можно прочитать в документе RFC 2086.

Далее после строки запроса следуют HTTP-заголовки. Описание каждого заголовка начинается с новой строки и представлено в виде:
ЗАГОЛОВОК: ЗНАЧЕНИЕ.

Рассмотрим заголовки, которые отсылает браузер в нашем примере.

• Host. Значением для этого заголовка должно быть доменное имя и порт запрашиваемого ресурса. Значение представляется в виде:

  ДОМЕННОЕ_ИМЯ:ПОРТ

  Порт можно не указывать. В этом случае предполагается, что используется порт по умолчанию — в нашем случае это порт 80.

  В нашем последнем примере для этого заголовка устанавливается значение example.com, т.е. браузер отправляет запрос на сервер example.com и хочет обратиться к файлу /index.php с переданным GET-параметром category=1.

• User-Agent. Содержит информацию о клиенте, который инициировал запрос к серверу, а также его программное обеспечение. Значение этого поля описывает ряд компонентов клиента. Оно может быть множественным, где все значения отделены друг от друга через пробел.

  В нашем последнем примере значением этого заголовка является:

  Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.8

  Здесь описываются параметры браузера и операционной системы — браузер Mozilla Firefox 3.0.8, основанный на движке Gecko, операционная система Linux Suse 11.1 оконной системой X11, процессор с архитектурой i686.

  Этот заголовок используется для статистических целей.

• Accept. В этом заголовке клиент передает список форматов, которые допустимы для ответа. Значение этого поля хранит список допустимых форматов, разделенных через запятую. Кроме того, для каждого формата можно указать уровень предпочтения от 0 до 1. Если уровень предпочтения не указан, то он считается равным 1. Значение в этом поле должно соответствовать виду:

  ФОРМАТ1[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ1],ФОРМАТ2[;q=УРОВЕНЬ_ПРЕДПОЧТЕНИЯ2]…

  В нашем примере браузер в этом заголовке посылает значение:

  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

  Его можно прочитать следующим образом: браузер предпочитает ответы в форматах text/html, application/xhtml+xml. Если сервер не может послать ответ в этих форматах, то браузер будет ожидать ответ в формате application/xml. Если же и в этом формате сервер не может послать ответ, то браузер примет ответ в любом формате.

• Accept-Language. Этот заголовок аналогичен заголовку ACCEPT, только здесь браузер сообщает серверу о своих предпочтениях о естественных языках, в которых должен приходить ответ.

  В нашем примере значением заголовка является:

  ru,en-us;q=0.7,en;q=0.3

  Браузер сообщает серверу, что ждет ответ на русском языке, но также примет ответ на «американском английском» и английском языках.

• Accept-Encoding. Подобен ACCEPT. В этом заголовке браузер указывает какое кодирование к содержимому допустимо в ответе. Кодирование содержимого необходимо для сжатия или других его преобразований.

  В нашем примере в ответе для браузера допустимо сжатие программой gzip и механизмом deflate:

  gzip,deflate

• Accept-Charset. Этот заголовок браузер посылает, чтобы сообщить серверу о своих предпочтениях кодировки ответа.

  В нашем примере этот заголовок принимает значение:

  windows-1251,utf-8;q=0.7,*;q=0.7

  Браузер ждет ответ от сервера в первую очередь в кодировке windows-1251, но также примет ответ в любой кодировке.

• Keep-Alive. Заголовок Keep-Alive содержит значение, которое означает в течение какого времени в секундах будет удерживаться соединение. Этот заголовок следует отправлять только в том случае, если заголовок Connection содержит значение keep-alive.

  Поддерживается только для протокола HTTP версии 1.1.

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

• Connection. Информация о проводимом соединении. В нашем примере этот заголовок принимает значение keep-alive, которое говорит серверу о том, что браузер хочет установить постоянное TCP соединение.

  До появления постоянных соединений для запроса каждой страницы сайта устанавливалось отдельное соединение. Открытие каждый раз отдельного соединения требует дополнительной нагрузки на сервер.

  Например, браузер может запрашивать какую-то страницу с изображениями. После получения HTML страницы ему нужно будет запросить с сервера каждое изображение. При каждом запросе изображения будет открываться отдельное TCP соединение, что приведет к дополнительной нагрузке.

  Использование постоянных соединений решает эту проблему. Если обе стороны (клиент и сервер) их поддерживают, то, в случае приведенного примера, HTML страницы и каждое изображение могут быть получены за одно TCP соединение.

  Заголовок Connection поддерживается только для протокола HTTP версии 1.1.

  Этот заголовок также может принимать значение close. В этом случае клиент сообщит серверу, что после принятия HTTP-запроса соединение должно быть разорвано.

А теперь давайте рассмотрим параметры HTTP-ответа, который отправляет сервер браузеру.

Первая строка — это строка состояния, которая состоит из следующих полей, разделенных пробелом:

• Версия протокола HTTP. В нашем ответе от сервера в этом поле содержится HTTP/1.x. Сервер поддерживает протоколы HTTP 1.0 и 1.1.
• Код состояния ответа. С возможными кодами состояния можно ознакомиться в документе RFC 2068. В нашем случае от сервера нам необходим код состояния ответа, равный 200, который означат, что запрос браузера был выполнен удачно.
• Комментарий. Комментарий для кода состояния. Если код состояния 200, то комментарий будет «OK».

За строкой состояния следуют HTTP-заголовки, каждый начинается с новой строки. В нашем примере сервер отсылает следующие HTTP-заголовки:

• Date. В этом заголовке хранится дата в формате RFC 822, описывающее когда отправляемый ответ был сгенерирован. Но это теория, на практике значением этого заголовка может быть любое время.

  В нашем примере в этом заголовке содержится:

  Tue, 21 Jul 2009 17:09:54 GMT.

• Server. В этом заголовке содержится информация о программном обеспечении, которое используется на сервере, а также его компонентах. Если ответ от сервера направляется через proxy, то используется заголовок «Via».

  В ответе от сервере на наш запрос содержится следующее:

  Apache/2.2.3 (CentOS)

  Это означает, что на сервере используется web-сервер Apache версии 2.2.3. В качестве операционной системы используется дистрибутив Linux CentOS.

• Last-Modified. В этом заголовке сервер сообщает дату последнего изменения какой-либо сущности — файла, базы данных и т.п. В нашем случае сервер отправляет дату последнего изменения файла index.php.

  Этот заголовок важен для браузера при использовании механизма кеширования. При обращении к какой-либо странице браузер кеширует ее. При повторном обращении к этой странице браузер, основываясь на заголовке Last-Modified проверит не устарела ли страница, сохраненная в кеше. Если нет, то браузер не будет еще раз считывать данные, а выведет страницу из кеша.

  В ответе сервера из нашего примера в этом заголовке хранится:

  Tue, 15 Nov 2005 13:24:10 GMT

• Etag. В этом заголовке содержится метка объекта ресурса. В нашем случае в качестве объекта выступает файл index.php.

  Наряду с заголовком Last-Modified значение этого заголовка используется при кешировании браузером. При первом запросе страницы браузер сохраняет значение Etag для страницы. При повторном запросе страницы значение Etag, которое пришло от сервера, сравнивается с тем, которое хранится в кеше браузера. Если они равны, то браузеру нет смысла считывать еще раз данные страницы, он просто возьмет их из кеша.

  В нашем примере в ответе сервера Etag имеет следующее значение:

  “b80f4-1b6-80bfd280″

• Accept-Ranges. Этот заголовок сообщает клиенту о том, что он может запрашивать данные с сервера фрагментами, указывая их смещение в байтах.

  Используется для реализации скачивания файлов с докачкой.

  В нашем примере сервер поддерживает эту возможность, о чем он и сообщает, передав в заголовке Accept-Ranges значение bytes.

  Зная эту возможность, браузер может передать серверу смещение в байтах, с которого необходимо начать передачу файла. Для этого браузер посылает заголовок Range с параметром bytes, значение которого и является смещением в байтах. Например:

  Range: bytes=2048

  Этот заголовок означает, что браузер запросил у сервера содержимое файла, начиная с 2-го мегабайта.

• Content-Length. Этот заголовок содержит размер тела HTTP-ответа сервера.
  В нашем примере размер тела сообщения 40.

• Connection. Как и в случае для клиента, этот заголовок предоставляет информацию о проводимом соединении. В нашем примере этот заголовок принимает значение close, которое говорит клиенту о том, что сервер либо не поддерживает постоянное TCP соединение, либо он просто отказывает браузеру в постоянном соединении.

• Content-Type. В этом заголовке содержится формат тела HTTP-ответа сервера.

  В нашем примере в этом заголовке содержится:

  text/html; charset=UTF-8

  Это означает, что сервер отвечает браузеру данными в формате text/html и кодировке UTF-8.

  В этом заголовке сервера также может храниться, например, «text/css; charset=utf-8» при ответе браузеру на запрос файла CSS. Или, например, может храниться «image/gif» при ответе браузеру на запрос GIF-изображения.

  О других форматах тела сообщения в ответах сервера читайте в RFC 822.

После HTTP—заголовков в ответе сервера содержится 2 перевода строки, за которыми следует само тело сообщения. 2 перевода строки служат разделением между параметрами ответа сервера и телом сообщения, в котором содержится html, отображаемый браузером.

В нашем примере в теле сообщения ответа от сервера содержится:

<p>This is a main page of example.com</p>

Ну а теперь напишем простой прокси-сервер на PHP, который покажет практическое использование упомянутых HTTP-заголовков.

<?php
$body = "";
// доменное имя передаем в GET-параметре $_GET['host']
$host = $_GET['host'];
// открываем сокет на стандартном для HTTP порту 80
$hSocket = fsockopen($host, 80, $errno, $errstr, 30); 
if ($hSocket)
{
    // первой строкой идет строка запроса
    $request = "GET / HTTP/1.1\r\n";
    // указываем доменное имя
    $request .= "Host: $host\r\n"; 
     // пусть мы будем для сервера браузером Mozilla Firefox
    $request .= "User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.8) Gecko/2009032600 SUSE/3.0.8-1.1.1 Firefox/3.0.\r\n";
    // указываем форматы, в которых будем ожидать ответ от сервера
    $request .= "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"; 
    // языки, на которых ожидаем ответ
    $request .= "Accept-Language: ru,en-us;q=0.7,en;q=0.3\r\n"; 
    // указываем какое кодирование к содержимому допустимо в ответе. 
    //Только в этом случае нужно будет раскодировать содержимое.
    //$request .= "Accept-Encoding: gzip,deflate\r\n"; 
    // выставляем предпочтения для кодировок ответа
    $request .= "Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7\r\n"; 
    // будем удерживать постоянное соединение в течение 300 секунд
    $request .= "Keep-Alive: 300\r\n";
    // открываем постоянное соединение
    // здесь мы завершаем передачу HTTP-заголовков, 
    // поэтому в конце обязательно указываем 2 перевода строки
    $request .= "Connection: keep-alive\r\n\r\n"; 
    // посылаем HTTP-заголовки через открытый сокет
    fwrite($hSocket, $request); 
    // флаг, указывающий на то, что считывается тело запроса
    $bIsData = false; 
    while (!feof($hSocket)) // считываем ответ от сервера
    {
        $str = fgets($hSocket, 128); // построчно
        if($bIsData)
        {
            $body .= $str; // тело запроса записываем в переменную $body
        }
        // встретилась строка, содержащая только перевод строки, это означает, 
        //что дальше пойдет тело запроса
        elseif($str == "\r\n") 
        {
            $bIsData = true;
        }
    }
    fclose($hSocket); // закрываем сокет
 
    // указываем на то, чтобы web-сервер отправил браузеру заголовки 
    // Last-Modified, Connection и Keep-alive
    header("Last-Modified: Tue, 21 Jul 2009 17:09:54 GMT", true);
    header("Connection: Keep-Alive", true); //
    header("Keep-Alive: timeout=30, max=100", true);
    // передаем тело запроса
    echo $body;
}
 
// работа php-скрипта закончена, теперь web-сервер отправляет ответ браузеру
?>

Чтобы отправить заголовки серверу, необходимо сначала открыть сокет. Сокет — это программный интерфейс, который позволяет обмениваться данными между процессами. При этом процессы могут выполняться на разных компьютерах, связанных сетью.

В нашем случае один процесс — это процесс браузера, второй — это процесс web-сервера, запущенный на удаленном компьютере.

В PHP сокет открывается функцией fsockopen. Далее в переменную $request мы записываем все нужные нам заголовки и отправляем их серверу функцией fwrite. После этого мы построчно считываем ответ сервера пока не будет достигнут конец данных (feof). После получения ответа мы отправляем этот ответ браузеру вместе с заголовками, которые в PHP выставляются функцией header.

Этот скрипт принимает через GET-параметр доменное имя сайта и отправляет к нему HTTP-запрос, считывает ответ и отдает этот ответ web-серверу, который отправляет его браузеру.

При помощи подобного скрипта вы можете сами поиграться с отправляемыми HTTP-запросами.

Нам этом все. Спасибо за внимание.

Для тех, кто заинтересовался и хочет подробнее изучить HTTP могу посоветовать следующие ссылки:

http://ru.wikipedia.org/wiki/HTTP – статья, подробно описывающая HTTP.

http://www.faqs.org/rfcs/rfc2068.html – документ RFC 2068.

Нашей целью является объединить людей этой профессии для оказания помощи друг другу в прохождении собеседования, составлении резюме, накоплении знаний.

В разделе “Вопросы на собеседовании” мы будем выкладывать самые распространенные вопросы, которые задает работодатель соискателю, откликнувшемуся на его вакансию программиста. Раздел будет постоянно пополняться, сейчас в нем можно найти вопросы по PHP, C++, .NET и базам данных.

В разделе “Вакансии” вы сможете найти самые свежие объявления от работодателей для программистов. Раздел обновляется несколько раз в день.

Мы также предлагаем вам проверить свои знания, посетив раздел “Тесты”. Зарегистрированные пользователи при желании могут разместить свой тест, который им предлагали пройти на собеседовании, а затем в личном кабинете следить за статистикой прохождения теста другими пользователями сайта.

В разделе “Книги” собраны книги для программистов. Здесь можно найти литературу по самым разным IT-тематикам: устройство компьютера и работа с “железом”, языки программирования и алгоритмы, компьютерные сети, а также многое другое.

Если вы опытный программист:

Если вы начинающий программист:

Итак,

• если вы готовитесь к собеседованию или вам просто интересно узнать о самых распространенных вопросах на собеседовании, то вам сюда.
• если вы в поисках работы, то посетите раздел Вакансии для программистов, в котором всегда самые свежие предложения от работодателей.
• если вам есть, что рассказать, или вы хотели бы получить ответ на какой-либо вопрос от более опытных коллег, вам сюда. Вы также можете разместить свою статью, для этого необходимо будет пройти простую процедуру регистрации.
• если вы хотите проверить свои знания, то вам в раздел Тесты для программистов.

Присоединяйтесь к нашей группе Вконтакте.

Следите за нашими вакансиями в Twitter  

Желаем удачи,
Команда Job-Interview.ru