풀스택을 위한 도커와 최신 서버 기술(리눅스, nginx, AWS, HTTPS, 배포까지) [풀스택 Part3]
안녕하세요, 인바운드 규칙 설정 문의드립니다. [강의 내 docker 주요 규칙 익히기 5 강의] 현재는 AWS통해서 gui를 통해, 인바운드 규칙 생성해주시는 법을 알려주셨는데요. 만약 제가 사용하고 싶은 서버가 특정 그룹안에서 만들어진 서버 (리눅스 기반)라면, 어떻게 인바운드 규칙을 설정할 수 있을까요? (aws free tier 사이트처럼, 사용자에게 친숙하게 제공되지 않을거 같아서요) 환경마다 다를거 같아서 직접 인바운드 규칙 설정하는 방법을 알려 주시기는 번거로우실거 같은데, 혹시 정확히 제가 어떻게 검색을 하면 질문드린 부분을 해결할 수 있을지 답변주시면 감사하겠습니다. (아직 서버, 리눅스 이런 부분에 대한 용어가 익숙치 않아서요) 미리 감사드립니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 저는 평소에 클라이언트에서 받은 요청 내용을 기억해서 (예를 들어 체크박스 표시한 list와 함께 다음페이지로 이동) 다른 URL에서 처리하기 위해 Forward를 사용한 경험이 있고, 요청 내용을 기억하나 못하나로 Redirect와의 차이라고 생각했습니다. 근데 이 강의를 통해 307 요청 내용을 기억하는 방법도 있다는 것을 보고, 흥미를 가져 http 응답의 start-line을 임의로 변경해서 바디를 유지해보고 싶단 생각이 들었지만, 일반적으로 redirect 시 302 코드만 보였고 307로 임의로 바꾸는 방법은 제 지식의 한계상 검색 범위가 좁아서 안나오더군요... 물론 당연히 실무에 필요한 방법은 아니겠지만! 서버에서 HTTP 메소드인 GET POST 등 지정할 수 있듯이 HTTP의 상태코드를 지정할 수 있나 궁금해서 물어봅니다!
"EC2 Auto Scaling - 동적 조정" 페이지에서 단계 조정과 단순 조정의 차이점을 이야기하면서 휴지 기간 발생 유무를 설명하는데, 이 차이가 바뀐거 같습니다. 페이지에서는 단계조정 : 휴지기 발생해 응답이 나중에 수행 단순조정 : 휴지기 없어서 스케일링 중에도 응답 수행 그런데 AWS 가이드 보다 보니 반대로 되어 있더라고요. https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/as-scaling-simple-step.html#SimpleScaling 그래서 한번 더 확인 부탁 드립니다.
안녕하세요, 강의를 듣고 로그인 하는 과정에서의 궁금증이 생겨 질문 남깁니다. 로그인할 때 유저의 id,비밀번호를 body에 넘기고 있는 사이트를 우연히 발견하게 되면서 보안에 굉장히 취약할 거란 생각을 하게 되었고 몇몇 유명 사이트들을 확인해보니 대부분 네트워크탭 payload에 담기지 않는 것을 확인했습니다. 조금 더 찾아보니 세션id를 활용하는 경우 서버에 로그인 요청할 때 authorization 헤더에 base64로 인코딩해서 전송하는 basic authentication 방식이 있는 것을 확인했습니다. 궁금한 것이 제가 찾아본 내용이 실무에서도 사용되고 있는 방식인지 그렇지 않다면 유저정보를 어떤 방식으로 body에 담지않고 서버에 전송할지 있는지 궁금합니다.
안녕하세요! 동일한 쓰레드가 write_lock을 잡고 있을 때는 read_lock을 잡을 수 있지만 read_lock을 잡고 있을 때에는 write_lock을 잡을 수 없다는 것 까지는 이해가 됐습니다. 그래서 ReadLock() 메소드에서 같은 쓰레드가 write_lock을 잡고있는지 체크를 해서 잡고있다면 단순하게 read flag를 1 증가해서 통과해주고 있죠. 근데 그렇다면 WriteLock() 메소드에서는 동일한 쓰레드가 read flag로 0을 갖고있는지 확인해야 하는 것 아닌가요? R -> W가 허용되지 않는다면, write_lock을 시도 할 때에 동일 쓰레드의 read flag가 0인지 체크하는 코드가 없어도 되는 이유가 뭔지 궁금합니다!
안녕하세요! 강사님. 클라이언트를 500명으로 늘렸을 때 말로 설명해주신 부분에서 이해는 가는데, 일부분이 정확하게는 이해가 가지 않는 부분이 있습니다. 작업이 밀려버리면 스레드풀에서 보낸 스레드가 돌아오지 않으니 새로운 스레드를 만들기때문에 메모리가 점점 찬다 -> 스레드가 패킷을 async하게 recv한 다음 jobqueue에 push를 할 때, push 하기위해 lock이 있으니 해당영역에서 병목현상이 발생하고, 그로인해 blocking된 스레드가 오지 않으니 스레드풀에서 새 recv가 오면 스레드 재사용이 아니라 새 스레드를 할당하기 때문에 스레드는 각 스레드별로 stack을 가지고 있기 때문에 이런 스레드별로 가지고있는 용량이 계속 증가하는거라서 메모리가 늘어난다. 라고 이해를 했었습니다. 그런데 나중에 다시 말씀해 주셨을 때, 일이 계속 밀리면, 스레드풀에서 스레드가 돌아오지 않으니 새로운 스레드를 만들고, sendbuffer에서 큰 단위의 버퍼에서 짤라서 사용하는걸로 구현했기 때문에 메모리가 계속 늘어난다. 라고 하셨는데, sendbuffer는 여러 스레드가 큰 버퍼에서 짤라서 각자 쓰는 것으로 이해를 했었어서 여러 스레드가 써도 큰 버퍼는 그대로고 얼마나 sendbuffer를 사용하는 횟수가 많아지냐. 가 달라지는거라고 생각이 들었는데,,, 그게 아닌가요? sendbuffer에서 큰 단위의 버퍼에서 짤라서 사용하는 것이 메모리 증가에 무슨 영향이 있는지 잘 이해가 되지 않습니다.
안녕하세요 ! 어렵지만 열심히 반복해서 서버 강의를 듣고있는 학생입니다. 다름이 아니라 iocp 서버로 Lobby를 제작하고 dedicated server로 InGame을 제작해서 2개의 서버를 함께 돌리려고 합니다. iocp server로 Lobby Level을 구성하고 3명이 한팀을 이뤄 MatchMaking을 통해 dedicated server로 만들어진 InGame Level로 넘길 생각입니다! iocp server와 dedicated server를 연결해두고, 클라이언트들을 옮기는 방식을 쓰려고 구상을 했는데, 제가 만든 iocp server와 dedicated server를 어떻게 연결할지 감이 안와서 질문드립니다. 혹시 이 방법이 불가능한지에 대해서도 여쭙고싶습니다. 감사합니다
안녕하세요, 강사님! GameRoom에서 client -> server로 보낸 메세지를 다른 client들에게 broadcasting을 하는데, 그래서 출력 결과가 10개씩 나오는 이유가 10개의 클라이언트들이 보낸걸 다시 반환하는것이기 때문에. 즉, 반사가 10개씩 나오는거고, 근데 클라이언트 console창이 하나로만 되어있다보니 10개의 클라이언트가 받은 반사메세지가 한번에 출력되어 10개씩 출력되는 것이라고 이해를 했습니다. 그런데 각 session이 어떤 순서로 반사를 받는지 궁금하여 client의 serversession에도 sessionid를 부여하고 테스트로 출력을 해 본 결과 아래와 같았습니다. session이 send 를 하는 것은 async로 구현하였기 때문에 비동기방식인데, 저렇게 규칙적으로 받아오더라구요.(4 2 3 1 5 0 6 7 8 9 ...순서) Program.Room .Enter(this); 를 한 순서대로 GameRoom의 _sessions 리스트에 추가가되니 Broadcast 때 리스트를 foreach하니까 리스트에 추가된 순서대로 오는 것 같다고 생각이 드는데, 사실 네트워크 상태에 따라서 패킷이 라우터에 경로가 달라지니 각기 다른 순서로 올 수도 있고(이건 그렇게 부하가 큰편은 아니니 그래도 해당 원인은 무시한다고 쳐도), 멀티스레드이기도 하고 thread context switching 으로 인해 스레드간 순서가 마구마구 뒤바뀔거라 예상을 했지만, 저렇게 규칙적으로 나오는 이유가 무엇인지 궁금합니다. 그리고 새로 실행 시 마다 저 규칙이 변경이 되는데, 그 이유는 사실Listener에서 Onconnected를 하여 Program.Room .Enter(this); 안에 들어가는 순서가 멀티스레딩이라서 다르게 들어가기 때문이라고 이해를 했습니다. 그렇다면 멀티스레딩으로 인한 순서 뒤바뀜이 있다는 증거이고 사실 listener가 받는 것 또 한 GameRoom에서 broadcasting하는것과 비슷하게 lock을 걸고 순서대로 session list에 추가하고 즉, 순차적으로 여기서 리스트 순서대로 보내도 순서뒤바뀜이 일어나서 GameRoom에서의 List에 쌓이는 순서도 바뀌는거라고 생각이 들거든요. 그러면 SendForEach에서 ServerSession리스트를 보낼 땐 멀티스레드로 인해서 순서가 뒤바뀌는데, Server의 GameRoom에서 ClientSession 리스트를 뽑아 send할 땐 순서가 유지되어 send보내지는 이유는 뭔가요?
강의와 이전 질문들을 토대로 클라이언트와 서버가 먼저 TCP 3-way 연결을 하고 완료가 되면 http 요청과 응답을 주고받는 다고 이해하였습니다. 그런데 http는 기본이 연결을 유지하지 않는 모델로 한 번 요청과 응답이 끝나면 연결이 끊긴다고 하셨는데요,그럼 http 연결이 끊길 때 때 TCP/IP 연결까지 끊는 것인가요? 그래서 요청을 보내고 싶을때마다 TCP 연결을 다시 해야하는 것이 한계인건가요? 또한 최적화로 지속 연결을 한 HTTP/2 같은 경우엔 TCP/IP 연결을 끊지 않는건가요?
