  |
はてなキーワード: httpとは
あたなは何か勘違いしているナリ
HTTPプロキシは基本的に CONNECT メソッドを通じて通信するナリ
それ以外の場合は socks プロトコルで通信するナリ（なので基本的に Proxy を通すとは HTTPプロキシを通すということで、その場合 CONNECT メソッドが必ず必要）
CONNECT は基本的にHTTPメソッドを経由して通信するが socks は HTTP とは全く異なるプロトコルなり
（プロトコルというより通信のレイヤーが異なる。socksはISO参照のセッション層だがHTTPはアプリケーション層）
nginx, varnish, apache など適当なサーバーに自分でプロキシを建てて nc, telnet で通信してみればよく分かると思われる
ちなみに当職のおすすめのハッキング本は Hacking Exposure 7 ですを
ttp://www.amazon.co.uk/Hacking-Exposed-Network-Security-Solutions/dp/0071780289
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
newnakashima エンジニアになって楽して年収１億稼ぎたいとか思ってるカモを集めて1ヶ月でPython + Flask でサイト作らせて「これで君もエンジニアだ！（笑）」でボロ儲けしてるプログラミング教室知ってる。
簡単なフレームワークを使うのは、細かいカスタマイズやチューニングができない代わりに、HTTPなどの本質的な概念の説明に注力できるからだと思っていましたが、こういう不心得者（業者も生徒も）がいるのですねぇ。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。
CDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。
これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタイムに更新していくことができる。 next.js + vercel などはこのあたりをフロントエンドから CDN まで一気通貫に提供することでリアルタイム風にコンテンツを更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。
CDN の設定の反映の遅さというのは Cloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。
ただし上記の特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点を比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害はマジで全部落ちたのでこれとは関係ない問題だろう)。
Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。
大抵のユーザーは Web からの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルのスニペットをアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードを VCL でやってしまって、同じ URI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。
ただし VCL でいろいろな制御を実現しようと思うと、 VCL の表現力の低さにより地獄を見ることになるので、得られるベネフィットと相談しながらこのあたりはやっていくことになる。
バグとは、実装意図と異なる挙動をすること。脆弱性とは、情報セキュリティ上の欠陥を指す。
例えばhttp通信でクレジットカード情報をやり取りするようなサイトが未だに残っていたとしたら、実装意図に沿ったものであったとしても、脆弱性だ。
今回の件は、開発着手時点から、このようにしか作れないことがわかっていたのだから、このように作ったというもので、実装意図に沿った挙動だよ。
一方で、接種者が自分の接種番号を公開してしまうと、自分の予約情報や接種履歴、東京に住んでいるか大阪に住んでいるかがわかってしまうという点では脆弱性だよ。
あとは、悪意のある人が、でたらめな番号で予約を占有するスクリプトを組めば、誰も予約できなくなっちゃうという意味でも脆弱性だね。
こっちはどうでも良くないので、外国やVPNやTorの疑いのあるIPアドレスを遮断して、ログから疑わしいアクセスがないか注視するのが良いだろうね。
横浜市で、対象人数が30万人くらいしかいない老人のワクチン予約サイトに200万件のアクセスが集中した件。
これは、サイトの作りが良くないことに起因する。
自治体のサイトのHTMLソースを見てみると分かるが、30～40ファイルくらいの外部ファイル（JavaScript、CSS、画像）がそのページから読み込まれているのが常だ。
つまり1ページの画面表示をするために30～40回のアクセスが発生する。
で、予約などの動的コンテンツの場合は、想定外のトランザクション不具合発生抑止や、申込途中のページが検索エンジンに拾われないようにすることなどを理由に、キャッシュを保持しない仕様としているのが普通だ。
そのため、ブラウザのキャッシュ機能が使えず、1ページ移動するたびに30～40回のアクセスが発生する。
2万人が4ページくらい画面遷移すれば200万アクセスを優に突破する計算だ。
「なんで対象が30万人しかいないのに200万アクセスも来るのか」という理由はここにある。
本来は、この手の動的サイトでは外部ファイルはクライアントサイドではなくサーバーサイドで呼び出して、HTTPアクセス自体は1ページ当たり数回に抑えるべきなのだが、そうなっていないようだ。
これ一部の人以外には全く起きない現象だから、現状を訴えると完全にはてな側の問題なのに「お前が荒らすから」みたいな扱いを受けてかなり消耗してたんだ。
今までわざわざwifi切ってスマホから書き込みしてて（というかこれで書き込めるからアカウントに問題があるわけではないことは明らか）、それで慣れてしまったのでツールは使わないかもしれんけど、これではてな側がなにかしら考えてくれるとありがたい。あまり期待できないが。
しかし人間性センターは本当にはてなの悪いところを煮詰めたような部分だよ。技術力がなく、ユーザーの不便は放置。未だにhttpで内容は露悪的で人を小馬鹿にしたようなもの。不快にさせる要素しかない。
ParlerというSNSがAWSからサービス停止されたと報じられています。
AWS、トランプ支持者のSNS「Parler」へのサービスを1月10日に停止
これに先立って、GoogleやAppleもParlerのモバイルアプリ配信を停止しているようです。
HTTPの404や500エラーが表示されるのでしょうか？試しに、今(2021/1/12)現在parler.comにブラウザでアクセスしてみると
このサイトにアクセスできませんparler.com のサーバーの IP アドレスが見つかりませんでした。
次をお試しください
ERR_NAME_NOT_RESOLVED
となりました。ERR_NAME_NOT_RESOLVED言っており、名前解決できていないようです。
プロバイダのDNSではなくPublic DNSを使って名前解決を試みても、IPアドレスの回答を得ることができませんでした。恐らくは有効なAレコードまたはCNAMEのエントリが存在しない状態になっているのでしょう。
$ nslookup parler.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: parler.com Address: 0.0.0.0
・CloudflareとAPNICのPublic DNS
$ nslookup parler.com 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: parler.com Address: 0.0.0.0
IPアドレスは引けなくなっていますが、ドメイン名自体は有効なのでしょうか？
whoisで確認してみると、parler.comのドメイン名は健在であることが判ります。Updated Dateが2021-01-11になっていますので、AWSにサービス停止された後に何らかの操作をしたように見受けられます(何もしていなければAWSを向いたままで、404とか500エラーが拝めたのでしょうか？)。
また、Epikというレジストラでドメイン名を取得(もしくは維持)していることが判ります。このレジストラ、私は聞いたことなかったのですが、調べてみるととんでもないことが書いてあります。Wikipediaより引用すると、
Epik is an ICANN-accredited domain registrar and web hosting company known for providing services to websites that host far-right, neo-Nazi, and other extremist content.
極右、ネオナチ、過激派にサービス提供していることで知られるレジストラかつWebホスティング企業だそうです。
…ホスティングもやっているなら、Parlerのサービスもここに移して再開されるかもしれませんね…
ちな、保●速報はCloudflare使っててサーバーの実態不明、ドメインはバリュードメイン。リ●ラはAWSで、ドメインはENOM, INC.ってとこ使ってるみたいですよ。
決済で使ってる三井住友銀行から、ロンダリング防止の確認のためのweb提出を求められたんだが、苦痛に耐えつつ8割くらい進んだ所でエラーが出て、入力分が全部喪失してしまったので、やめてしまった。回答いただけないと利用制限とか警告書いてあるけど、無視してやる。
https://infoweb.smbc.co.jp/hojin/
以下、ダメすぎてムカついた点
https://www.iseto.co.jp/company/profile.html
なんだか歴史だけは御大層な会社に依頼して作ってるらしいけど、学生サークルのイベント参加フォームだってもっと丁寧に作るだろ。金とっていい仕事じゃないよこれ。こんなの納品されてOKだしてる銀行のIT部門も相当クソ
infoweb.smbc.co.jpが、httpからhttpsにリダイレクトする設定がされてないから、ブラウザでアドレス打ち込むときに、しっかりhttpsから打ち込まないと、目的のページにはたどり着かないってのが原因だ。スマホのときは、QRコード使ってhttpsのほうにアクセスしたからつながったってことか。
SSL使ってるちゃんとしてるはずの企業で、こんなクソサイト初めてだわ。http→httpsのリダイレクトなんてSSL対応の基本の基本なのにな…SSL対応のお仕事は会社設立以来初めてやりましたって会社なのか？こんな素人感丸出しだと、もっと重要なところでもやらかしてそうで、金預けてて大丈夫か心配になるわ。
http://infoweb.smbc.co.jp/hojin/
