인프런 스프링부트 개념정리(이론)
이 글은 다음 강의의 이론 정리 글 입니다.
Spring은 따로 톰캣을 설치할 필요 없이 바로 실행 가능하다.
먼저 톰캣을 무엇인지 알려면 Socket이 뭔지 알아야한다.
Socket은 운영체제가 가지고 있는 것으로 A와 B가 서로 메세지 교환을 하고 싶을 때 소켓을 사용한다. 먼저 A, B가 메세지 교환을 하려면 A 서버가 소켓을 열어야 하는데, 이때 포트 번호(5000)가 필요하다. B가 A랑 소통하고 싶으면 A의 주소(IP 주소)와 포트 번호(5000)를 넣는다. B가 5000번에 연결이 되는 순간 A와 B는 메세지를 교환할 수 있다.
A와 B가 연결되면 C는 A 서버의 5000번 포트를 사용하지 못하게 된다.(B가 사용중이기 때문에) 이렇게 A 서버와 연결하고 싶어하는 애가 많을 경우, 최초의 5000번 포트는 연결의 용도로만 쓴다.(계속 새로운 사용자의 연결을 받는 용도) 5000번 포트에 연결이 되는 순간 새로운 소켓을 만들고, 이 새로운 소켓의 포트 번호(5001)는 랜덤으로 만들어진다. 그럼 B가 5000번과의 연결이 끊기고, 새로운 소켓(5001번 포트)으로 연결이 돼서 소통이 가능해진다.
이렇게 5001번이 연결이 돼서 계속 소통을 하게 되면, cpu가 5001번에서 일하고 있기 때문에 다른 소켓들이 일을 할 수가 없다. 따라서, 5001번의 새로운 소켓을 만들 때는 새로운 스레드를 만든다. 5000번 포트는 main 스레드를 사용 중인 것이고, 5001번은 스레드1을 사용 중이다. 이제 C가 연결을 시도하면 먼저 5000번에 연결했다가 5002번 포트(스레드2)가 만들어지고 main 스레드와의 연결을 끊고 스레드2와 다시 연결될 것이다.
이렇게 소켓 통신이라는 것은 스레드(thread) 개념을 알고 있어야 하고, 스레드가 있으면 time slice를 해서 동시에 동작하는 것처럼 보이게 한다는 점을 알고 있어야 한다. 다만 이런 소켓통신은 연결이 계속 되어있기 때문에 연결이 100명, 1000명이 되면 생각보다 부하가 크고 느려질 수 있다. 하지만, 한번 연결되면 계속 연결되어있기 때문에 A 서버에서 B, C가 누군지 계속 알고 있다는 장점이 있다.
반면, http 통신(웹 통신)은 연결을 지속되지 않고 연결을 끊어버리는 stateless 방식을 쓴다. http 통신은 단순하게 문서를 전달하는 통신인데, 예를 들어, A가 "a.txt 파일 좀 줘"하고 80번 포트 소켓으로 C 서버에 연결하면 얘가 새로운 스레드를 만드는 것이 아니라 바로 a.txt를 찾아서 주고 연결을 끊어버린다. 마찬가지로 B도 다시 80번 포트 소켓으로 "b.txt 좀 줘"하면 C 서버가 찾아서 주고 연결을 끊어버린다.
연결을 끊어버리기 때문에 부하는 적지만, 다시 연결하면 이미 연결한 적이 있음에도 불구하고 항상 새로운 사람으로 인식한다. 예를 들어 A가 다시 c.txt를 달라고 C 서버에 요청하면 C 서버는 a.txt를 달라고 했던 애와 c.txt를 달라고 했던 애가 동일한 애인지 구분을 하지 못한다.
이런 단점들을 보완하면서 만들어진게 웹서버다.
스위스에 cern 연구소(입자물리연구소)가 있다. 여기에는 다양한 나라의 사람들 수만명이 모여서 연구를 한다.
A라는 사람이 연구를 해서 논문을 만드려고 한다. 그러면 A는 전세계에 있는 자신의 주제와 동일한 내용의 논문을 다 읽어봐야한다. 인터넷이 없던 시절의 종이 문서나 컴퓨터는 있었던 시대에 각 컴퓨터마다 저장되어있는 논문들을 다 읽는다. 게다가 이 논문들이 전부라고 보장도 못한다.
이 때, 팀버너스리(http의 창시자)라는 사람이 모든 사람들이 가지고 있는 컴퓨터를 전부 한 서버에 연결하고, 각자 논문들을 이 서버에 다 업로드하게 했다. 그러면 서버에서 논문을 서치해서 가져올 수 있게 되었다. 한번 필요한 논문을 들고 오면 더이상 연결이 필요가 없다. 따라서 소켓 통신을 기반으로 하지만 한번 요청이 끝나면 연결을 끊는 http 통신이 등장한다.
이렇게 html 확장자로 만들어진 문서를 찾는 것과 문서 전달이 http의 목적이었다.
요즘 팀버너스리는 다시 데이터를 이렇게 중앙집중화하지 않고 분산화시켜 블록체인처럼 개인이 데이터를 통제하는 솔리드 프로젝트를 진행중이다.
웹의 아버지가 웹을 바꾸겠다 선언
‘내 데이터가 어디에 저장될지 내가 결정한다’
추가 읽어볼 거리 (References)
https://bentist.tistory.com/35
https://kotlinworld.com/75?category=999308
http는 운영체제가 갖고 있는 소켓을 이용해서 만들어졌다. 이렇게 운영체제가 갖고 있는 서비스를 요청하는 것을 시스템 콜이라고 한다. http의 기반은 소켓이다.
이제 우리는 톰캣과 웹서버의 차이를 알고 있어야한다.
내가 컴퓨터를 하나 샀다. 그리고 나는 재밌는 동영상들 3개를 가지고 있다. 친구들은 컴퓨터가 각각 있다. 이 친구들이 내 동영상을 보고 싶어 한다. 나는 친구들의 컴퓨터에서 원하는 것이 없다.
친구들: 우리는 월드 와이드 웹으로(선으로) 연결되어있어. 그러니까 인터넷 통신을 통해서 너가 들고 있는 동영상을 나에게 줄 수 있겠니?
이 상황에서 내가 갑, 친구들이 을이 된다.
여기서 나는 웹서버이다. 즉, 웹서버가 갑이고, 갑은 을이 필요한 데이터를 가지고 있다.
을이 갑한테 request(요청)한다. request를 하기 위해서는 갑의 IP주소를 알아야 한다. 그리고 1, 2, 3번 동영상 중 어떤 데이터가 필요한지를 명시를 해줘야하기 때문에 url(uniform resource location 자원을 요청하는 주소 ex. http:~/a.html, http:~/a.avi)로 표시한다. 자원의 위치를 요청해서 내가 필요한 정보를 얻어올 수 있다.
참고사항
uri vs url
이제 갑은 을에게 해당 데이터를 response(응답)를 해준다. 응답할 때 갑의 입장에서 갑은 을 컴퓨터에 가서 데이터를 가져올 일이 없기 때문에 을의 IP는 몰라도 된다. 갑은 항상 가만히 있다가 을이 요청을 하면 을이 요청한 IP를 토대로 자기가 누군지를 밝히고, 그 정보를 토대로 다시 응답해주면 된다.
이렇듯 http에서 갑은 을의 IP주소를 모른다. 즉, 요청하지 않았을때 응답해줄 수 없다. 을의 주소를 알려면 연결이 지속되는 소켓 통신을 써야한다. 하지만 http통신은 단순하게 요청시에 응답만 해주는 구조고, 응답은 단순하게 html 문서 혹은 특정 자원에 대해서 하는데, 이 자원들은 static(정적) 자원들이다.
웹서버는 흔히 아파치를 사용한다.
내 컴퓨터에 특정 폴더를 지정하고 사람들한테 공유하려한다. (C:/work)
work 폴더 안의 자원을 요청하면 아파치가 그 자원을 응답해주고 끝난다.
만약 요청하는 자원이 .jsp
나 자바코드로 적혀있는 자원을 요청하게 되면 아파치는 자바코드를 이해하지 못해서 응답할 수 없다. 그래서 아파치에 톰캣을 달면 아파치가 이해하지 못하는 자원을 받았을때 톰캣한테 제어권을 넘겨버린다.
톰캣 안에서는 .jsp
안에 있는 모든 자바 코드를 컴파일해서 .html
로 덮어씌워서 아파치에 다시돌려주면 아파치가 .html
를 응답해준다.
웹브라우저가 .jsp
파일을 요청했을때 웹서버가 .jsp
파일을 그냥 찾아서 돌려주기만 한다면, 웹브라우저는 html, javascript, css, 정적인 자원(avi 등)만 이해할 수 있기 때문에 .jsp
파일을 받으면 내용이 깨져버릴 것이다. 그래서 아파치는 톰캣과 함께 작동하여 .html
파일을 웹브라우저에 보내주는 것이다.