배포 2
CS=> 컴퓨터 사이언스
컴퓨터 내부원리를 알아야 문제를 진단하고 해결하는것이 가능. (CPU문제인지, 등을 파악이 가능하다.)
http , https(보안관련)
네트워크와 트러블 슈팅
지난시간: http로 정적사이트를 스토리지로 배포함.
http => 주의요함.
https => 자물쇠형태
두가지는 무엇이다른가.
네트워크 + 트러블슈팅(발생한 문제를 해결하는법)
와이어샤크를 통해 데이터가 나가는것을 볼 수 있다. 와이파이로 나가는것도 확인이 가능하다.(데이터 주고받는것 확인가능) =>
두 컴퓨터간에 데이터가 왔다갔다하는것을 보여주는 그 하나하나를 패킷이라고 하는데 이 페킷을 보여주는 도구중하나.
소스(Source = src): 출발지를 의미
Destination(dst): 목적지(도착지)를 의미
리다이렉트 : http(:80)으로 접속하더라도 자동으로 https(:443)으로 접속되게 돌려주는것.
80은 포트번호. 실제로 접속 시에는 양쪽에 둘다 포트가 있어야함. 따라서 랜덤 포트번호를 받아서 80서버(벡엔드서버)로 요청
추가 => 2진수 4개가 16진수. 이 둘은 서로 바꾸기 쉬움.http의 경우:
==> 입력한 이메일과 패스워드가 노출이 된것을 볼 수 있다.
https로 접속한경우:(http + scure)
Encrypted => 암호화 된것을 확인할 수 있다.(전부 암호화되어 보기 어렵다)
3-way-handshake
브라우저와 벡엔드의 연결과정.
1. 브라우저에서 백앤드 연결 가능여부 요청 - SYC(싱크 = 동기화)
2. 요청한 결과로 연결가능하다는 것 보냄 - SYC + ACK
3. 브라우저와 벡엔드 연결 - 브라우저가 벡엔드에 -ACK
여기에 FIN이 추가되면 4-way-handshack
매번 3-way-handshake가 일어나는가?
==> 아니다. 일정시간이 정해져있고 그동안 아무 활동이 없다면 종료된다.
(매번 일어난다면 느리기때문이다.)
ip주소 확인하는법
dig로 도매인 정보를 확인할 수 있는데, dig 도매인주소 A 라고치면 해당 도메인의 A레코드를 볼 수 있고 여기서 해당 도메인의 ip를 볼 수 있다.
ARP스푸핑:
와이파이를 해킹해 해당 와이파이를 사용하도록유도하여 정보를 빼가는 형식.
http를 사용자가 접속했다면 암호화가 안되어있기에 쉽게 빼갈 수 있다.
방화벽
브라우저에서 프론트 서버로 접속하는데 이게 https라면 방화벽으로 막혀있어 당장은 방화벽 해제가 안되어있어 접속되지 않는다.
==> 방화벽을 해제해야한다.
브라우저에서 api요청. -> 오래걸림>>?? && 방화벽은 3000번은 열림. 이유: api가 오래걸림.
브라우저api요청 -> 오래걸림. -> 이유: 방화벽막혀 아예 들어갈 수 없음
==> 이 두가지 모두 브라우저 상에서는 pending으로 보임.
이외에도 많은 가능성들이 있는데 이때는 네트워크 패킷을 확인해봐야정확히 알 수 있다
dig 도메인주소 A 로 ip를 알아내고,
와이어샤크 등으로 검색
아예 연결자체가 튕겨나가는 중 --> 방화벽 막힘문제.
https로 변경하기 위해서는 ssl인증서가 필요하다.
인증서:? 암호화 되어있는 문자열. 어것을 적용하면 https로 접속이 가능해짐.
ssl의 업그레이드 버전이 TLS인증서!!
-
브라우저에서 LB로 https요청을 하고싶을때는 LB에 인증서를 설치해야한다.-> 대부분의 클라우드에서 제공함.(쉬움)
-
LB에서 내가만든 인스턴스에 https접속을 하고싶을때는 이 인스턴스에 설치하면되는데 복잡하고 어려움.
두가지 방법 :
- 복잡하고 어렵더라도 직접 LB와 인스턴스에 설치하기.
- LB에만 설치하고 이 요청을 LB에서 인스턴스로 보낼때 http로 갈 수 있게 바꿔준다(리버스 프록시)
두가지 방법 다 사용하는데, 내부적으로도 보안이 필요하다면 1번을, 누가 의도적으로 해킹할 이유가 없는... 그런 사이트라면 주로 2번 방법을 사용.
(어차피 첫 접속에서 https로 접속하게 되면서 막아주기때문에)
=> 리버스 프록시
헬스체커: 서버에 응답을 보내며 서버가 죽었는지 살았는지 일정시간마다 확인하고, LB에 알려주는 역할
CDN에도(클라우드 프론트 - 정적, 동적 분기시키는 애)붙일 수 있다.
2단계에서도 CDN을 추가해 여기 붙여도 된다.
1단계에서 CDN붙여서 완성하기.
그리고 4단계로가기
AWS에 CDN에 인증서 설치하기
현재: DNS를 통해 스토리지 배포함.
순서: 먼저 인증서 설치: ACM -> 지역은 버지니아 북부.
-> 클라우트 프론트(얘의 지역은 없음(글로벌)) 만든 후 연결.
컴퓨터와 브라우저의 물리적 거리가 가까워야 빠름.(서버 위치가 가까워야함)
클라우드 프론트 - CDN서비스 ...그리고 ACM
왜??
CDN이란?
Content Delivery Network
서버에 배포후 내용들을 전세계에 뿌림: 임시저장(캐싱 )이라고함. 이렇게 뿌려놓는것을 CDN이라고하고 따라서 얘는 글로벌 이라고함.
우리는 가까운곳에있는 서버에 접속해 사용하는 형식
따라서 CDN에 붙이는 아이이기에 글로벌로 선택해야하는데, 이때.. 가장 기본 주소로 ACM을 만들어야함(아마존정책)
만약 서브도메인을 만들어 해당 주소에 인증서를 만들기위해서는 도매인 주소의 인증서와, 서브도메인이 붙은 도메인 주소의 인증서 두가지 다 발급받아야한다.(인증서는 얼마든지 만들 수 있다)
현: DNS에서 스토리지로 바로 가고있음.
이것을 CDN을 통해 가도록하기.
CloudFront에서 생성하는데, 원본도메인을 자동완성된것을 선택하지말고 s3의 속성 맨아래쪽의 주소를 복사해 http://부분만 지운다.(주소가 다르기에 s3에서 복사해옴)
--
ssh: 시큐어 쉘(터미널 의미)
127.0.0.1 => 로컬호스트
프라이빗 아이피 = 내부아이피 벡엔드와 DB를 VPC라고함.
퍼블릭 아이피 = 외부아이피
밖에 브라우저에서 접속하려는것을 외부아이피, 내부에서 자기들끼리 사용하는것을 내부 아이피 라고함.(내부에서 왔다갔다하므로 속도 빠름)
EC2컴퓨터 생성.
curl -sL https://rpm.nodesource.com/setup_14.x | sudo bash
앞으로 노드js설치할건데 14버전으로 설치할거야 하고 기록해놓는 명령어
TCP => 서로 계속 소통하면서 확인하면서 데이터 주고받는것 -> 안정성은 높으나 느림.
UDP => 확인없이 계속 보내는것. => 속도빠름. 안정성 낮음.
