第一部達成基準#
第一部における各課題の達成基準を次のようにまとめます．
Day2からDay5までの必須課題（単位取得のための必須項目）#
Day2 「必須課題1〜10」までを実施する（レポートへの記載は不要）
Day2 「入出力性能の計測結果（必須）」内の必須課題1および2を実施し、結果について報告する
Day3 「性能計測」の結果について報告する
Day4 「HTTPベンチマークプログラムの実装」内の必須課題1および2の結果について報告する
Day5 「複数クライアント対応」内の必須課題（select/fork/pthread/Apacheでの実装）の結果について報告する
Day5 「複数クライアント対応」内の必須課題、「性能比較」の結果について報告する
Day5 「セキュリティホール」内の必須課題を全て実施して結果について報告する
Day5 「HTTPサーバ機能拡張（選択）」について1つの機能を選択して実装する
なお、性能比較等において設定する計測条件については各自で工夫すること
発展課題（必須ではないが加点となる）#
Day3 「非同期IOによる多重化」の結果について報告する
Day3 「通信失敗の原因分析」の結果について報告する
Day4 「HTTPベンチマークプログラムの実装」内の発展課題の結果について報告する
Day5 「複数クライアント対応」内の発展課題の結果について報告する
Day5 「セキュリティホール」内の3つの発展課題について1つ以上を実施し報告する（複数実施すればより多く加点される）
Day5 「HTTPサーバ機能拡張（選択）」について2つ以上の機能を実装する
また，レポート取り組みにあたっては，まずはグループリーダーを決めてください（もちろんグループリーダーが全責任を負うわけではありません．リーダーを担当することでグループワークの苦労を実感すると思いますが，就職活動等でアピールできる経験になりますから一度は担当してみた方がよいです．また，メンバとしての役割も重要ですから，リーダーに求められること，メンバに求められることが何かも意識してみてください）．グループリーダーを中心に班員全員が各項目を理解できるよう話し合いをし，必須課題のそれぞれの実装の詳細まで全員で理解を深めてください．まずは必須課題のそれぞれを分担して実装してください．それぞれの実装を共有してお互いに実装内容を説明し合って理解を深めてください．もし興味深い実装をしている人がいたら，その部分を強調してアピールしてください（内容によりますが加点要因として考慮します）．
達成基準に関するもう少し詳しい解説#
「必須課題1〜10」までの実施#
以降の実験に必須ですので，正しく動作することを確認しておきましょう． これらについては実施は必須ですがレポートへの記載は必要ありません．
「入出力性能の計測結果（必須）」#
readとfread, writeとfwriteはどちらも似たような関数ですが，そもそも何が異なる関数なのでしょうか？ まずはそれを調べた上で，バッファサイズの増減がそれぞれの動作にどのような影響を与えるのか仮説を立てましょう． 仮説を立てた上で，その仮説を検証するための実験条件を立てて実験を進めてください．
複数クライアント対応（必須）#
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つの機能拡張を行うことを条件としています． たとえば，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への対応
などなど