HTTP : hypertext transfer protocol.
자. 영어 그대로 해석해보자. hypertext를 전송해주는 규약.
하이퍼텍스트를 전송한다고? 누군가 텍스트를 위/변조가 가능할 수 있겠다. 라는 문제점이 하나 있겠고, 평문 통신이니까 도청이 가능하겠지. 별 다른 암호화가 안들어가있잖아
또한 통신 상대를 확인하지 않기 때문에 MITM에 약하겠고, 완전성 증명이 안되기 때문에 변조 또한 가능하다.
=> 암호화를 진행하지 않은 프로토콜이라면 다 비슷하겠지. 하지만 HTTP는 특히 체크썸도 없고 평문 통신이잖아..
큰 문제점 1. TCP/IP는 도청 가능한 네트워크이다.
도청 못하게 해결하려면 어떻게 해야할까?
=> 통신 자체를 암호화해보자. SSL(Secure Socket Layer) 가능.
HTTP 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 부른다.
HTTP의 메시지만 암호화하는 거. 어떨까? request 메시지를 받은 입장에서도 그 암호화에 대한 해독기능을 가지고 있어야 가능하겠지.
큰 문제점 2. 통신 상대를 확인하지 않는다는 점.
=> 누구든지 리퀘스트 가능하고, 누가 리퀘스트했는지 모르고, 의미없는 리퀘스트, 반복적인 리퀘스트 다 받아버리면 서버 과부하걸리면 어떡할래?
해결 방법 : SSL로 상대를 확인할 수 있다. 증명서를 하나씩 부여시킬게.
큰 문제점 3. 완전성을 증명할 수 없기 때문에 변조가 가능하다는 점
정보를 내가 위/변조 시켜도 얘가 알아볼 수 없잖아. 확인할 수 있는 길이 없어.=> MITM
해결 방법 : MD5, SHA-1 해시 값 확인이라던지.. 이런건 확실히 확인할 수 없다.
확실한 방지 방법은 HTTPS야.
결국 이 세개의 해결 방법은 전부 다 HTTPS네. HTTPS는 HTTP에 대한 보안을 강화한거니까 문제로 언급되어왔던 것들을 전부 해결하기 위해서 만들어진 것이겠지?
속도도 HTTPS가 더 빠르대. 신기해
HTTPS : HTTP에 암호화, 인증, 완전성 보호까지 더한 놈
원래는 HTTP - TCP - IP 통신이잖아. 하지만 SSL을 더해주면서 HTTP - SSL - TCP - IP 가 됐어. 그래서 TCP는 한번에 HTTP로 들어올 수 없고... 모든 웹페이지에서 HTTPS를 안쓰는 이유는 리소스가 많이 필요하기 때문이야.
DNS : Domain Name System. 내가 아이피를 어떻게 기억해
www.naver.com 에서 .com이면 어디 아이피 대역으로 보내고, naver면 어디 IP 대역으로 보내고 해서 계속 대역을 점차 줄여나가면서 내가 원하는 IP에 연결해주는 느낌.
도메인 네임 시스템을 이용해서 내가 편하게 웹에 접근할 수 있다..
DNS round robin 방식의 문제점
서버의 수 만큼 공인 IP 주소가 필요하다. 부하 분산을 위해 서버의 대수를 늘려야 하는데
그 늘린 만큼의 공인 IP 주소가 필요하잖아.
균등하게 분산되지 않음. -> 한쪽에 편향되는 현상이 일어날 수 있겠지.
서버가 다운되어도 확인할 수 없다는 단점을 가지고 있음. -> 어떤 원인으로 다운된지 모르거든.
WBR(weighted round robin) 웹 서버에 가중치를 가미해 분산 비율 나눠..
Least Connection : 제일 연결 적은 놈에게 연결시켜!
웹 통신의 큰 흐름
우리가 크롬을 실행시켜서 주소창에 특정 URL 값을 넣으면 어떻게 될까?
브라우저딴) url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 의미를 조사
조사의미에 따라 HTTP request 메시지 만들기
만들어진 메시지를 웹 서버로 전송한다. 메시지 전송은 브라우저가 직접 하는게 아니야. OS가 도와줌.
HTTP : hypertext transfer protocol.
자. 영어 그대로 해석해보자. hypertext를 전송해주는 규약.
하이퍼텍스트를 전송한다고? 누군가 텍스트를 위/변조가 가능할 수 있겠다. 라는 문제점이 하나 있겠고, 평문 통신이니까 도청이 가능하겠지. 별 다른 암호화가 안들어가있잖아
또한 통신 상대를 확인하지 않기 때문에 MITM에 약하겠고, 완전성 증명이 안되기 때문에 변조 또한 가능하다.
=> 암호화를 진행하지 않은 프로토콜이라면 다 비슷하겠지. 하지만 HTTP는 특히 체크썸도 없고 평문 통신이잖아..
큰 문제점 1. TCP/IP는 도청 가능한 네트워크이다.
도청 못하게 해결하려면 어떻게 해야할까?
=> 통신 자체를 암호화해보자. SSL(Secure Socket Layer) 가능.
HTTP 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 부른다.
HTTP의 메시지만 암호화하는 거. 어떨까? request 메시지를 받은 입장에서도 그 암호화에 대한 해독기능을 가지고 있어야 가능하겠지.
큰 문제점 2. 통신 상대를 확인하지 않는다는 점. => 누구든지 리퀘스트 가능하고, 누가 리퀘스트했는지 모르고, 의미없는 리퀘스트, 반복적인 리퀘스트 다 받아버리면 서버 과부하걸리면 어떡할래? 해결 방법 : SSL로 상대를 확인할 수 있다. 증명서를 하나씩 부여시킬게.
큰 문제점 3. 완전성을 증명할 수 없기 때문에 변조가 가능하다는 점 정보를 내가 위/변조 시켜도 얘가 알아볼 수 없잖아. 확인할 수 있는 길이 없어.=> MITM
해결 방법 : MD5, SHA-1 해시 값 확인이라던지.. 이런건 확실히 확인할 수 없다. 확실한 방지 방법은 HTTPS야.
결국 이 세개의 해결 방법은 전부 다 HTTPS네. HTTPS는 HTTP에 대한 보안을 강화한거니까 문제로 언급되어왔던 것들을 전부 해결하기 위해서 만들어진 것이겠지? 속도도 HTTPS가 더 빠르대. 신기해
HTTPS : HTTP에 암호화, 인증, 완전성 보호까지 더한 놈
원래는 HTTP - TCP - IP 통신이잖아. 하지만 SSL을 더해주면서 HTTP - SSL - TCP - IP 가 됐어. 그래서 TCP는 한번에 HTTP로 들어올 수 없고... 모든 웹페이지에서 HTTPS를 안쓰는 이유는 리소스가 많이 필요하기 때문이야.
DNS : Domain Name System. 내가 아이피를 어떻게 기억해 www.naver.com 에서 .com이면 어디 아이피 대역으로 보내고, naver면 어디 IP 대역으로 보내고 해서 계속 대역을 점차 줄여나가면서 내가 원하는 IP에 연결해주는 느낌. 도메인 네임 시스템을 이용해서 내가 편하게 웹에 접근할 수 있다..
DNS round robin 방식의 문제점
WBR(weighted round robin) 웹 서버에 가중치를 가미해 분산 비율 나눠..
Least Connection : 제일 연결 적은 놈에게 연결시켜!
웹 통신의 큰 흐름
우리가 크롬을 실행시켜서 주소창에 특정 URL 값을 넣으면 어떻게 될까?
브라우저딴) url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 의미를 조사 조사의미에 따라 HTTP request 메시지 만들기 만들어진 메시지를 웹 서버로 전송한다. 메시지 전송은 브라우저가 직접 하는게 아니야. OS가 도와줌.
프로토콜 스택, 어댑터딴) 브라우저로부터 메시지받고, 패킷속에 메세지 넣고, 수신처 주소 제어정보 덧 붙이고, 패킷 넘기고..
허브,스위치,라우터딴) 패킷 전달..
웹서버딴) 웹서버에 패킷이 도착하면 메시지 복원하고, 어플리케이션에 넘기고, 데이터를 응답메시지에 넣어서 클라이언트에게 회송.