쟈쟈의 코딩일기

클라이언트에서 서버에 로그인 요청을 보내고 서버에서 로그인의 성공 응답을 보내주는 로그가 있다고 가정해보자.

로그인 인증정보가 맞다면 사용자는 화면에서 로그인을 성공했다는 화면을 확인 할 수 있다. 그런데 우리는 서버로부터 로그인 성공 화면 외에도 다른 것들을 받는다. 그 대표적인 것으로 쿠키(cookie)가 있다.

쿠키

쿠키는 서버에서 클라이언트로 보내져서 브라우저에 저장되는 아주 작은 크기의 데이터이다.

쿠키는 속성을 나타내는 키와 그 속성에 해당되는 값을 가지고 있으며, 명시된 유효기간이 만료된 시점에 브라우저에서 삭제되는 특징을 가지고 있다.

우리가 로그인을 성공한 이후의 작업을 가정해보자. 쇼핑사이트를 예시로 들면 장바구니를 이동하거나 여러 물품을 검색하거너ㅏ 개인정보를 수정하는 등 페이지를 이동할 것이다. 클라이언트가 자유롭게 페이지를 이동하며 여러가지 자원을 활용할 수 있는 이유는 로그인을 성공하여 회원임을 인증하였기 때문이다. 그러나 장바구니에 이동하는 회원이 로그인을 성공했다는 것을 클라이언트와 서버가 요청 자체는 기억하지 못한다. HTTP 통신에서는 각각의 요청과 응답이 독립적이다. 그렇기 때문에 이전의 작업을 기록하지 못한다. HTTP는 각각의 요청과 응답이 종료되었을 때, 연결이 지속되지 않고 상태를 기억하지 않는다는 특징을 가지고 있는데 이것을 Stateless 혹은 무상태성이라고 한다. 수천 명, 수만 명이 동시에 서버에 접속하면 거대한 컴퓨팅 리소스를 하게 되며 서버가 온전히 버틸 수 없는 상태가 될 것이다. 그렇기 때문에 Stateless 속성이 리소스 측면에서는 효율적이다. 그리고 요청을 어딘가에 남기기 위해 고안된 것이 바로 쿠키이다.

서버가 클라이언트에게 작업을 성공해서 데이터를 보내겠다는 쿠키를 보내면, 쿠키를 받은 클라이언트는 로그인을 하고 다른 페이지로 이동해도 로그인이 풀리지 않게 된다. 쿠키가 없었다면 페이지를 이동할 때마다 로그인을 해야할 것이다. 브라우저에 저장된 쿠키에 의해 클라이언트는 로그인 했거나 장바구니에 물건을 추가하는 등 서버와 있었던 작업들을 받게 되고 서버는 다시 클라이언트에서 보낸 쿠키 정보에 따라 작업을 기억하고 다시 브라우저에 내용을 띄워주는 역할을 한다.

그러나 쿠키는 취약점이 노출되거나 악의적인 공격에 악용될 수 있어 민감한 데이터들은 최대한 남기지 않도록 해야한다. 서버에서만 쿠키값을 조작할 수 있도록 하는 httpOnly 옵션이나 보안연결에서만 쿠키값을 전송하는 secure를 활용하는 것이 좋다. 해킹이나 사용자 변조, 위장의 피해가 발생하지 않도록 하기 위해 개발자로 하여금 쿠키를 적절하게 활용하는 것이 중요하다.

세션

쿠키의 한계점을 보안하기 위해 나온 개념이다.

클라이언트에서 로그인 요청을 보내고 성공하게 되면 서버에서는 여러가지 정보들을 주는 것이 아니라 세션 아이디만 쿠키에 실어보낸다. 클라이언트의 상태를 나타내는 나머지 쿠키 데이터들은 서버 측의 세션 저장소에서 가지고 있는다. 클라이언트에서 불필요한 민감 정보나 보안에 접촉되는 데이터를 담지 않고 서버에서 세션 아이디를 받고 그 세션 아이디에 해당되는 정보를 찾아 활용하게 된다.

만약 로그인 이력이 있는 브라우저에서 다시 로그인 요청을 하게 되면 서버에서 세션 아이디가 세션 저장소에 있는지 먼저 찾아보고 아이디가 있다면 거기에 저장된 상태 데이터들을 기반으로 클라이언트에 응답한다.

세션은 민감한 정보가 클라이언트에 저장되거나 노출되어 변조되는 것을 방지하고 클라이언트가 매번 요청 시에 쿠키값을 보내는 리소스 비용을 절감한다. 그런데 세션 저장소는 서버 측 입장에서는 또하나의 비용이 들 수 있다. 그래서 서버 측에서 세션 저장소를 운용하는 가용성과 설계가 서버 성능에 영향을 미치거나 운영비에 변동을 줄 수 있다.

HTTP와 URL

광활한 인터넷 세계에서 클라이언트와 서버가 통신하기 위해서는 일정한 규칙이 필요하다.

웹브라우저에서 URL이라는 주소 양식을 통해 클라이언트와 서버가 통신하는 규칙을 HTTP라고 한다.

HyperText Transfer Protocol

하이퍼텍스트 전송규칙(규약)

하이퍼텍스트는 다른 페이지, 혹은 리소스로 이동할 수 있는 링크를 뜻한다. 인터넷 세상에서 각종 데이터들을 조회하고 활용하기 위해서는 여러 개의 페이지를 드나들 수 있어야한다. 그러기 위해 웹페이지 내에서 다른 페이지로 이동할 수 있도록 하는 것을 하이퍼텍스트라고 이름을 붙이게 되었다.

Uniform Resource Locator

인터넷 상에 위치하고 있는 각종 자원들의 주소 체계를 가르키는 말이다. 서버에 저장된 웹페이지, 혹은 유튜브의 비디오, 음악의 음성 등 모두 URL을 가지고 있다.

아래 링크를 예시로 URL의 구조를 살펴보자.

https://coding-study-o-o.tistory.com/43

프로토콜(Protocol)

통신 규칙을 정해 포함을 시키며 HTTP(HTTPS), FTP 등이 있다. 일반적으로 보안 처리가 되어있는 HTTPS 방식으로 통신하기 때문에 대부분의 http에 s가 붙어있다.

https://coding-study-o-o.tistory.com/43

호스트(Host)

서버의 주소

호스트 네임이나 루트 도메인이라고 지칭하기도 한다.

https://coding-study-o-o.tistory.com/43

경로(Path)

슬래쉬( / ) 뒤에 붙는 것.

호스트 내 서비스의 위치를 가르킨다. 서비스 별로 분할되는 경우가 많다.

쿼리 문자열(Query String)

위의 주소에는 없지만 ? 기호로 시작하고 &로 연결되는 URL 규칙이 있다. 키/값 쌍으로 구성되어있다.

쿼리 문자열은 연달아 붙일 수 있다. 입력한 검색어 뿐만 아니라 검색 기관이나 검색 조건을 연속적으로 구성할 수 있다.

Web

Web 이전에는 PC 통신이라는 것이 있었다. Web과 PC 통신의 차이는 PC 통신은 동일한 사업자끼리만 통신이 가능했고 저속이며 전화선/모뎀을 사용하지만 Web은 어느 곳에 있는 누구와도 통신이 가능하고 고속이며 광랜(FTTH)이라는 전용선을 사용한다.

Web 1.0 (1990년대 후반 ~ 2000년대)

어느 누구나 프로그램을 대중에게 공개할 수 있는 세상의 도래

초고속 인터넷이 가정에 보급되기 시작한 시기와 맥락을 함께하고 있다. 네이버, 다음. 야후, 라이코스 등 포탈, 커뮤니티 사이트가 등장했다. 뿐만아니라 지마켓, 옥션 등 인터넷 쇼핑과 버디버디, 네이트온, 사이월드 등 메신저 서비스 또한 활성화 되었다.

Web 2.0 (2010년대 ~ 현재)

일방향적으로 정보를 제공받던 사용자가 직접 정보를 생산하고 공유할 수 있게 됐다. 위키피디아, 네이버 블로그 등 오픈된 공간에서 다양한 정보를 주고 받는다.

스마트폰의 등장

아이폰으로 비롯된 스마트폰의 시대가 시작되었다. 언제 어디서나 고해상도에서 찍은 사진을 실시간으로 올리고 반응을 실시간으로 받을 수 있게 되었다. 스마트폰에 최적화된 IT 서비스 또한 대중의 생활에 깊숙하게 파고든다. SNS(소셜 네트워크 서비스)로 인해 사회 이슈를 전세계적으로 주고 받을 수 있게 되었다. 또한 zoom 등의 영상통화가 대중화 되었다.

Web 3.0 (현재 ~ )

현재 Web 2.0을 향유하며 3.0으로 전향되는 발전의 과도기를 겪고 있다.

데이터를 투명하게 공개해야한다는걸 가장 큰 가치로 여기며 Blockchain 기술이 등장했다. 블록체인이 가상화폐라는 새로운 형태의 열기에 힘입어 세간의 관심을 집중시키게 되었다.

블록체인은 누구나 분산된 원장을 통해 데이터를 변동사항이나 추가된 내역을 조회할 수 있으며 보안상으로도 전원의 합의가 필요하기 때문에 아주 안전하다 여기고 있다. 그러나 모든 참여자에게 원장을 갱신하고 전파하는 과정이 필요하기 때문에 네트워크 처리 속도가 느리고 오픈소스 형태로 관리되어 책임자가 불분명하기 때문에 해결 해야하는 문제가 남아있다.

클라이언트와 서버

인터넷 상의 정보를 활용하기 위해 우리는 크롬, 사파리 등 웹브라우저라는 도구를 사용한다.

노트북에서 크롬 웹브라우저를 이용하여 구글에 원하는 정보를 요청하는 상황을 가정해보자. 브라우저를 통해 요청(request)을 보내는 주체를 클라이언트(client)라고 한다. 그리고 요청에 대한 응답(response)을 전달하는 주체를 서버(server)라고 한다.

이렇게 우리가 사용하는 웹서비스, 웹 어플리케이션이 데이터를 어떤 방식과 형식으로 요청하고 응답받는지 차이가 있을 뿐, 전부 이러한 구조를 가지고 있다. 웹을 이해하는 것 또한 클라이언트, 서버 간에 요청과 응답을 파악하는 것으로부터 시작된다.

예외(Exceptions)

코드를 실행했을 때 발생되는 에러 중 하나. 예상할 수 있고 자바에서 그 유형을 가지고 있다.

int a = 10;
int b = 0;
int c = a / b;

10은 0으로 나눌 수 없다.

그렇기 때문에 이런 에러가 발생한다.

에러를 처리하지 않으면 프로그램이 종료되거나 예기지 못한 방향으로 흘러갈 수 있다. 컴퓨터 시스템 자체에서 처리될 수 있도록 회피하거나 대체적인 동작, 혹은 에러메세지를 띄울 수 있도록 처리해야한다.

리스트를 통한 예외를 만들어보자.

ArrayList arrayList = new ArrayList(initialCapacity:3);
arrayList.get(10);

10이라는 값은 arrayList에 존재하지 않는다. 자료구조에서 범위를 벗어난 것을 참조할 때도 예외가 발생한다.

예외를 처리하기 위해서는 try와 catch 구문을 사용한다.

try는 예외가 발생할 것 같은 코드를 try 안에 넣는다. 어떤 예외를 잡아 판단할 것인지, 예외가 발생하면 대체 동작을 수행할 수 있도록 해주는 것이 catch이다.

try {
	arrayList.get(10);
} catch (Exception e) {
	e.printStackTrace();
    System.out.println("Exception 발생");
} finally {
    System.out.println("finally");
}

Exception은 가장 최상위에  e Exception이라는 객체가 있다. 모든 Exception은 여기에 포함된다. 그렇기 때문에 어떠한 에러가 발생하더라도 catch에 걸리게 된다. 그리고 중괄호 안에 메세지를 띄우거나 Sytem.out.println으로 콘솔에 에러발생이라고 띄울 수 있다.(그러나 웬만하면 catch 문 안에 Sytem.out.println을 쓰지 않는 것이 보안에 좋다.) printStackTrace는 에러와 관련된 내용을 띄워 확인 할 수 있다. 에러 메세지는 보안적으로 취약한 점이 드러날 수 있기 때문에 외부에 노출하는 것을 지양하는 것이 좋다.

finally는 위와 상관 없이 무조건 수행되는 소스를 가르킨다.

발생하는 에러 종류를 세분화해보자.

try {
    int a = 10;
    int b = 0;
    int c = a / b;
} catch (IndexOutOfBoundsException ioe) {
    System.out.println("IndexOutOfBoundsException 발생");
} catch (IllegalArgumentException iae) {
    System.out.println("IllegalArgumentException 발생");
} catch (Exception e) {
    System.out.println("Exception 발생");
} finally {
    System.out.println("finally");
}

catch는 다중으로 세팅할 수 있다. 예상되는 예외를 나열하고 가장 마지막에 최상위의 Exception 객체를 넣어야 처리되지 않는 예외 없이 모두 처리가 된다.