눈송이의 개발생활

다른 출처로의 리소스 요청을 제한하는 2가지 정책 CORS SOP 📕 Origin(출처)이란? protocol + host + port == origin(출처) 출처 : 서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐놓은 것 port는 생략 가능 http, https의 기본 port 번호가 지정되어 있기 때문에 BUT 출처에 포트 번호가 명시되어 있다면 port까지 모두 일치해야 같은 출처로 인정됨 ❓ 출처 비교는 누가? 브라우저! 출처를 비교하는 로직은 브라우저에 구현된 스펙 서버가 요청에 대한 응답을 잘 해줘도 브라우저가 분석했을 때 동일한 출처가 아니면 에러 발생 응답 데이터에는 문제가 없지만 브라우저가 차단한 것! SOP Same-Origin Policy 같은 출처에서만 리소스를 공..

토큰(Token) 인증에 대한 정보를 사용자가 저장 등장 이유 : 시스템의 규모가 커짐에 따라 서버(세션) 기반 인증 방식의 한계 드러남 웹/앱 어플리케이션이 발달하면서 서버 확장하기 어려워짐 서버가 각각의 클라이언트를 구분하기 위해 발급하는 클라이언트의 정보를 담은 암호화 데이터 요즘에는 JWT(JSON Web Token) 주로 사용 서버(세션) 기반 인증 방식 서버 측에서 사용자의 정보를 기억해야 함 사용자들의 정보를 기억하기 위해서는 세션 유지해야 함 메모리 or 디스크 or 데이터 베이스로 관리 Stateful server : 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스에 이용하는 역할의 서버 🔴 단점 세션(Session) 대부분 메모리에 세션 저장하는데 로그인 중인 사용자가 늘어나는 ..

쿠키와 세션의 필요성 HTTP의 약점을 보완하기 위해 사용 비연결형(connectionless) 무상태(stateless) 통신이 1번 되면 서버와 클라이언트의 연결이 끊어지기 때문에 서버는 클라이언트가 누구인지 매번 인증해야 함 이 번거로움을 해결하기 위해 쿠키와 세션을 사용 쿠키(Cookie) 사용자에 의해 조작되어도 크게 문제되지 않을 정보를 브라우저(client)에 저장 서버에서 사용자의 컴퓨터(client)에 저장하는 작은 기록 정보 파일 필요할 때 정보 참조 or 재사용 가능 💡 특징 클라이언트에 총 300개의 쿠키 저장 가능 1개의 도메인은 20개의 쿠키 가질 수 있음 하나의 쿠키는 4KB까지 저장 가능 유효시간 동안은 브라우저가 종료되어도 인증이 유지됨 Response Header에 Set..

TLS/SSL 인증서 클라이언트와 서버 간의 통신을 제3자가 보증해주는 전자화된 문서 공개키, 발급자, 유효 기간 등의 정보 포함하고 있음 CA(Certificate Authority) : 보증해주는 제 3자 통신 내용이 노출되거나 변경되는 것 방지 해당 서버가 신뢰할 수 있는 서버임을 보장 SSL 통신 과정 공개키 방식은 많은 컴퓨터 자원을 사용하는 단점이 있음 대칭키 방식은 효율적이지만 수신측과 공신측이 동일한 키를 갖게 되어서 보안상 문제가 발생한다는 단점이 있음 SSL은 암호화된 데이터를 전송하기 위해 공개키와 대칭키 혼합해서 사용 실제 데이터 : 대칭키 대칭키의 키 : 공개키 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화 → 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 ..

HTTP 종류 HTTP/0.9 ~ HTTP/2.0 : TCP 사용 HTTP/3.0 : UDP 사용 1️⃣ HTTP/0.9 단일 라인으로 구성된 요청 GET이 유일한 method HTML 파일만 전송 가능 2️⃣ HTTP/1.0 Header, Status code, Content-type 포함 1 request + 1 response / connection 매번 새로운 연결로 성능 저하 서버 부하 비용 증가 3️⃣ HTTP/1.1 persistent connection : 지정한 timeout 동안 connection을 닫지 않는 방식 pipelining 기법 도입 하나의 connection에서 응답을 기다리지 않고 순차적인 여러 요청을 연속으로 보내 그 순서에 맞춰 응답을 받는 방식 지연 시간 감소 단점..

HTTP Hyper Text Transfer Protocol 웹상에서 클라이언트와 서버 간에 요청/응답으로 데이터 주고 받을 수 있는 프로토콜 포트 번호 80번 사용 애플리케이션 레벨의 프로토콜 ⇒ TCP/IP 위에서 작동 비연결(connectionless) 클라이언트가 요청한 응답을 서버에서 보내면 바로 연결이 끊김 무상태(statelss) 연결 끊으면 서버의 통신은 끝나고 상태 정보를 유지하지 않음 Method, Path, Version, Headers, Body로 구성됨 단점 평문 통신이기 때문에 도청이 가능 통신 상대를 확인하지 않기 때문에 위장 가능 완전성을 증명할 수 없어서 변조 가능 HTTP Method 기능 설명 POST create body부분에 데이터 담김. 서버값 변경 GET read..

TCP TCP 3-way handshake가 완료되면 데이터 교환 시작 데이터 전송의 신뢰성을 확보하기 위해 흐름 제어, 혼잡 제어, 재전송 제어를 조합해가며 전송 unreliable network의 4가지 문제 손실 : packet 손실되는 문제 순서 바뀜 : packet의 순서 바뀌는 문제 congestion : 네트워크 혼잡 overload : 수신측(receiver)이 overload되는 문제 흐름 제어(Flow Control) 수신측(receiver) 단말이 수행하는 흐름(데이터 전달 속도) 양 조정 송신측(sender)이 수신측(receiver)보다 속도가 빠른 경우 문제가 발생 수신특에서 제한한 저장 용량을 초과한 이후 도착하는 데이터는 손실될 수 있음 위험을 줄이기 위해 수신측에 맞춰 송신..

네트워크 계층 중 전송 계층에서 사용하는 프로토콜 전송 계층 : 데이터의 전달 담당. 송신자와 수신자 연결하는 통신 서비스 제공 TCP(Transmission Control Protocol) 데이터를 메시지와 함께 보내기 위해 IP와 함께 사용하는 프로토콜 IP : 데이터 배달 처리 TCP : 패킷 추적 및 관리 연속성보다 신뢰성있는 전송이 중요할 때 신뢰성 : 데이터를 순차적으로 안정적이게 전달 전송 : 포트 번호에 해당하는 프로세스에 데이터 전달 TCP 특징 연결형 서비스(양방향 통신) → 가상 회선 방식 제공 3-way handshaking : 연결 설정 4-way handshaking : 연결 해제 흐름제어 제공 데이터 송신하는 곳/수신하는 곳의 데이터 처리 속도 조절해서 수신자의 버퍼 오버플로우..