세션 기반 인증 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful(상태 유지)한 구조를 가짐 서버에 세션을 저장해야하므로 서버에 부담이 상대적으로 더 가며 확장성이 낮음 또한, 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없음(세션 하이재킹 공격) 단일 도메인인 경우 사용 → 세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리하는 것은 어렵습니다. (CORS 문제) 토큰 기반 인증 상태 정보를 서버에 저장하므로 Stateless(무상태)한 구조를 가짐 단일 도메인이 아닌 경우 사용

가장 큰 차이는 사용자의 정보가 저장되는 위치 쿠키는 클라이언트, 세션은 서버의 자원을 사용 세션은 보안이 뛰어나다는 점과 쿠키는 요청 속도가 빠르다는 특징 쿠키 웹 서버와 클라이언트가 통신할 때, 클라이언트 쪽에서 가지고 있는 정보 HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요 시 정보를 참조하거나 재사용할 수 있음 세션 서버 쪽에서 가지고 있는 정보 일정 시간 동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술 쿠키(Cookie) 세션(Session) 저장 위치 클라이언트(=접속자 PC) 웹 서버 저장 형식 text Object 만료 시점 쿠키 저장 시 설정(브라우저가 종료되도, 만료시점이 지나지 않으면 삭제되지 않음) 브라우저 종료 시 삭제(..

HTTP Method 종류 기능 GET 데이터 조회 POST 요청 데이터 처리(보통 데이터 등록 사용) PUT 데이터 변경 (해당 데이터가 없으면 생성) PATCH 일부 데이터만 변경 DELETE 데이터 삭제 1) HTTP 1.0 단기 커넥션(shrot-live connections) : 요청 날릴 때마다 커넥션 맺고 끊어짐 Request를 날릴 때마다 Connection을 새로 생성해야 함 Data를 압축해서 전달 가능하도록 하여 전달하는 Data 양이 감소 2) HTTP 1.1 지속 커넥션(Persistent connection) : 커넥션 재사용 가능 HTTP 파이프라이닝(Pipelining) : Request를 미리 여러 개 서버에 날릴 수 있음 (이전엔 리퀘스트 하나보내고, Response 받고..

둘 다 HTTP 프로토콜을 이용해 서버에 무언가 요청할 때 사용하는 방식 GET 방식 URL을 통해 모든 파라미터를 전달하기 때문에 주소창에 전달 값이 노출됨 URL 길이가 제한이 있기 때문에 전송 데이터 양이 한정되어 있고, 형식에 맞지 않으면 인코딩해서 전달해야함 POST 방식 HTTP 바디에 데이터를 포함해서 전달 웹 브라우저 사용자의 눈에는 직접적으로 파라미터가 노출되지 않고 길이 제한도 없음 보통 GET은 가져올 때, POST는 수행하는 역할에 활용함 GET은 SELECT 성향이 있어서 서버에서 어떤 데이터를 가져와서 보여주는 용도로 활용 POST는 서버의 값이나 상태를 바꾸기 위해 활용

대칭키(Symmetric Key) 암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘 동일한 키를 주고받기 때문에, 매우 빠르다는 장점이 있음 but, 대칭키 전달 과정에서 해킹 위험에 노출 공개키(Public Key) / 비대칭키(Asymmetric Key) 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘 대칭키의 키 분배 문제를 해결하기 위해 고안됨.(대칭키일 때는 송수신자만 키를 알아야하기 때문에 분배가 복잡하고 어렵지만 공개키와 비밀키로 분리할 경우, 남들이 알아도 되는 공개키만 공개하면 되므로) 자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개함 공개키 암호화 방식 진행 과정 A가 웹 상에 공개된 'B의 공개키'를 이용해 평문을 암호화하여 ..

TCP 연결 지향형 프로토콜로 신뢰성있는 데이터 전송을 보장 신뢰적인 연결방식 서버와 클라이언트의 함수 호출 순서가 중요 서버 : socket() 생성 → bind() 소켓 주소 할당 → listen() 연결 요청 대기 상태 → accept() 연결 허용 → read/write() 데이터 송수신 → close() 연결 종료 클라이언트 : socket() 생성 → connect() 연결 요청 → read/write() 데이터 송수신 → close() 연결 종료 서버와 클라이언트의 차이 클라이언트 소켓 생성 후 서버로 연결을 요청하는 과정에서 차이가 존재 서버는 listen() 호출 이후부터 연결 요청 대기 큐를 만들어 놓고, 그 이후에 클라이언트가 연결 요청을 할 수 있음 이때 서버가 바로 accept()..