第二部達成基準#
第二部における各課題の達成基準は以下の通りです．
まずはグループリーダーを決めてください（もちろんグループリーダーが全責任を負うわけではありません．リーダーを担当することでグループワークの苦労を実感すると思いますが，就職活動等でアピールできる経験になりますから一度は担当してみた方がよいです．また，メンバとしての役割も重要ですから，リーダーに求められること，メンバに求められることが何かも意識してみてください）．
グループリーダーを中心に班員全員が各項目を理解できるよう話し合いをし，必須課題のそれぞれの実装の詳細まで全員で理解を深めてください．
まずは必須課題のそれぞれを分担して実装してください．それぞれの実装を共有してお互いに実装内容を説明し合って理解を深めてください．
もし興味深い実装をしている人がいたら，その部分を強調してアピールしてください（内容によりますが加点要因として考慮します）．
複数クライアント対応（必須）#
select()での実装#
最低限，以下を確認できればOKです．
test.htmlでSimple HTTPサーバと同じ結果が表示されること
Simple HTTPサーバよりも高性能なこと
fork()での実装#
最低限，以下を確認できればOKです．
test.htmlでSimple HTTPサーバと同じ結果が表示されること
Simple HTTPサーバよりも高性能なこと
pthreadでの実装#
最低限，以下を確認できればOKです．
test.htmlでSimple HTTPサーバと同じ結果が表示されること
Simple HTTPサーバよりも高性能なこと
Apacheでの実装#
最低限，以下を確認できればOKです．
test.htmlでSimple HTTPサーバと同じ結果が表示されること
Simple HTTPサーバよりも高性能なこと
独自方式での実装#
最低限，以下を確認できればOKです．
test.htmlでSimple HTTPサーバと同じ結果が表示されること
Simple HTTPサーバよりも高性能なこと
HTTPベンチマークプログラムの機能拡張#
最低限，1つのスレッドで複数のリクエストを発行するように拡張してください．それ以外にも様々な機能拡張方法がありますので，内容と難易度に応じて柔軟に加点したいと思います．
例えば，以下のようなHTTPサーバ機能拡張に合わせて，動作確認用にHTTPベンチマークプログラムも機能拡張するとよいと思います．
POSTへの対応
Keep Aliveへの対応
HTTPSへの対応
HTTP/2への対応
などなど
性能比較#
これまでに機能拡張したHTTPサーバやHTTPベンチマークプログラムソフトを使って，各実装方式での性能比較を行い計測結果をグラフ化してください．もちろん実験を行う前に，班員間でどのような実験結果になるのか十分議論し予想内容を整理してから性能比較実験を行ってください．
各実装方式の性能比較は，シェルスクリプト等を書くと作業が楽になると思います．グラフの表示は，gnuplot等を使用すると楽と思います．例えば，横軸を「HTTPリクエスト数」，縦軸を「応答時間」や「セッションエラー率」にしてグラフ化してみるといったことが考えられます．例えば応答時間に関して，「機能拡張したHTTPサーバ（各方式でどの程度違う？）＜ Apache ＜ Simple HTTPサーバ」といった結果が容易に想像できると思いますが，より深く検討と考察してみてください．
また，各条件での性能比較は，それぞれどのように実施すべきかも考えてください．基本的には，比較したい機能以外はほぼ同じ条件（ハードウェア構成，ソフトウェア設定，試行回数など）で実施しないと，公平な性能比較になりませんのでご注意ください．
「Webシステム 性能評価」とかで検索してみるとよいと思います．
参考情報#
「負荷試験の基礎知識」: 仲川樽八，森下健．”Amazon Web Services 負荷試験入門”, 技術評論社, p.35, 2017.
セキュリティホール（発展）#
バッファオーバーフロー#
サーバプログラムを実行した端末画面で「Segmentation Fault」が表示されるようなクライアントプログラムを実装できればOKです．
バッファオーバーフローしない対策#
上記のクライアントプログラムで接続されても，サーバプログラムが停止しなくなればOKです．
バッファオーバーランで任意のコマンドを実行#
例えば「date > /tmp/hacked」を実行して，/tmp/hacked というファイルにコマンド実行時の日時情報が記録できていればOKです．このコマンドが何をしているか（どのような意味があるか）は班員間でもしっかり相談し理解を共有しておいてください．
バッファオーバーランでリモートからシェルに接続#
クライアントプログラムを実行している端末から，リモートで動作しているサーバ側のコマンド実行を自由に行え，その結果をクライアント側に表示させられればOKです．
HTTPサーバ機能拡張（選択）#
3XX系ステータスコードへの対応#
最低限，Webブラウザのデバッグ機能を用いて以下を確認し，ページ遷移もできていることが確認できればOKです．それ以外の実装は難易度によりますが多少加点したいと思います（受け身ではなく自発的に取り組む姿勢を評価します）．
301
302
303
4XX系ステータスコードへの対応#
最低限，Webブラウザのデバッグ機能を用いて以下を確認し，ページ遷移もできていることが確認できればOKです．それ以外の実装は難易度によりますが多少加点したいと思います（受け身ではなく自発的に取り組む姿勢を評価します）．
401（Basic認証でのログインでよい）
403
418
Basic認証の実装#
最低限，Basic認証画面が表示されログインできることです．
例えば，.htaccess的なファイルを作成して工夫してみてください．
Digest認証の実装#
最低限，Digest認証画面が表示されログインできることです．
例えば，.htaccess的なファイルを作成して工夫してみてください．
各種メディアタイプへの対応#
最低限，10種程度のメディアタイプに対応させてください．
設定ファイルに記述するなどメディアタイプを追加できるような工夫など加点対象にします．
HTML5動画への対応#
Webブラウザ上で動画が再生できていることが確認できればOKです．
Ajaxへの対応#
最低限，以下を確認できればOKです．
Webブラウザのデバッグ機能でXMLHTTPRequestが見えること
XMLHTTPRequestで取得したデータをブラウザ上に表示できること
例えば，以下のような実装もあると思います（オリジナリティや難度を大きく重視したいと思います）．
サーバ上に日時の文字列を返すURLを用意
XMLHTTPRequestを用いてそのURLにアクセス
サーバから取得した日時をalertで表示
POSTへの対応#
最低限，HTMLのformから文字列をPOSTできればOKです．
もちろん，例えばファイルのアップロードなど様々な工夫があると思いますので自由な発想でアピールしてください．
CGIへの対応#
最低限，PHPで記述されたページを表示できればOKです．
さらに，GETやPOSTにも対応できていると様々なことができそうですね．
その他の機能拡張#
それぞれ仕様をどこまで実装するか任せますので，何をどこまで実装したのか，どの程度大変だったのか（どこかのソースコードそのまま流用したらできた，先輩に教えてもらった，など様々な方法が考えられますので），どの程度加点するのがよさそうか上手にアピールしてください．
それぞれの仕様を満たしているかどうか説明する方法は様々ありますが，例えばブラウザのデバッグ機能やWiresharkなどの結果を示しつつ説明するという方法もあります．また，それぞれの実装方法で意図した性能になっているのか性能比較してみるのもよいと思います．どのように伝えたいことを適切に説明できるかも重要ですのでここも加点ポイントになります．
Comet (long polling)への対応
Keep-Alive実装
SSE (Server Sent Events)への対応
WebSocketへの対応
WebWorkersへの対応
HTTPSへの対応
HTTP/2への対応
などなど